Getting double semi as sequencer harvested.
Locked
12345678
... 13
12345678
... 13
 
|
Andreas Raab wrote:
> Damien Pollet wrote: >> (*) just on this point I'd prefer to write something like >> {[a]. [:x| x b]. [:x | x c]} valueAsChain > > Nah. I want to write: > > [a. b. c] piped. > > SCNR, > - Andreas > > How would that evaluate? What is piped where to whom? b piped to a and c piped to the result of b piped to a? See, blocks can do almost everything! Who needs other syntax when we have blocks! ;-) Cheers, Peter |
Re: Fear and loathing of the "perification" of Smalltalk
|
|
In reply to this post by Andreas.Raab
On 05/09/07, Andreas Raab <[hidden email]> wrote:
> Damien Pollet wrote: > > (*) just on this point I'd prefer to write something like > > {[a]. [:x| x b]. [:x | x c]} valueAsChain > > Nah. I want to write: > > [a. b. c] piped. OK, but then please don't call [...] a block. Now it's an expression sequence, a parse tree, or whatever, but not a closure (or a very specific one) If [a.b.c] piped is possible, then [a.b.c] do: [:aStatement| aStatement value] should be possible to, shouldn't it ? Or [a.b.c] addStatement: [d] or [a.b.c] at: 2 put: [e] -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org |
|
|
In reply to this post by Mathieu SUEN
Mathieu Suen wrote:
> On Sep 5, 2007, at 12:53 AM, Peter William Lount wrote: > >> The curly braces require the same virtual machine statement evaluator >> upgrade as the blocks version does, do it's not any more magic than >> the curly braces are doing! The "objects" (or "values" if you prefer) >> message simply calls an appropriate virtual machine primitive to >> collect up the results of each statement. > > > No! the curly braces is not handle by the VM. Is translated by the > compiler. > > Mth > Oh, well putting it into the virtual machine is the best place for it in my view, but that's an implementation detail. Why is it the best? Performance and flexibility with all the capabilities fully realized. What does the Squeak Compiler convert curly braced code into? Certainly in another version of Smalltalk there will be two evaluators: one that returns the value of the last statement as normal, plus one that stores the results of each statement as it's evaluated into a collection. Cheers, Peter |
Re: Fear and loathing of the "perification" of Smalltalk
|
|
In reply to this post by pwl
On Sep 5, 2007, at 1:11 AM, Peter William Lount wrote:
> Andreas Raab wrote: >> Damien Pollet wrote: >>> (*) just on this point I'd prefer to write something like >>> {[a]. [:x| x b]. [:x | x c]} valueAsChain >> >> Nah. I want to write: >> >> [a. b. c] piped. >> >> SCNR, >> - Andreas >> >> > HI Andreas, > > How would that evaluate? What is piped where to whom? b piped to a > and c piped to the result of b piped to a? Same as: {[a]. [:x| x b]. [:x | x c]} valueAsChain Like in a linux shell: [:x | x c] value: ([:x| x b] value: [a] value) > > See, blocks can do almost everything! Who needs other syntax when > we have blocks! ;-) > > Cheers, > > Peter > > Mth |
Re: Fear and loathing of the "perification" of Smalltalk
|
|
In reply to this post by pwl
On 05/09/07, Peter William Lount <[hidden email]> wrote:
> Yes, "[a. b. c] value" returns one value, c, while "[a. b. c] values" > (or objects) returns three values in a collection. One could imagine > #valuesInArray, #valuesInOrderedCollection, #valuesInSet, #valuesIn: > aCollection, #valuesToStream:, etc... I would prefer to use the curlies notation for these uses and reserve the current block notation for lambdas. -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org |
|
|
In reply to this post by Damien Pollet
Damien Pollet wrote:
> On 05/09/07, Andreas Raab <[hidden email]> wrote: > >> Damien Pollet wrote: >> >>> (*) just on this point I'd prefer to write something like >>> {[a]. [:x| x b]. [:x | x c]} valueAsChain >>> >> Nah. I want to write: >> >> [a. b. c] piped. >> > > OK, but then please don't call [...] a block. Now it's an expression > sequence, a parse tree, or whatever, but not a closure (or a very > specific one) > tree or whatever. Why wouldn't it? The key is in how it's evaluated. With a block that can be chosen at run time whereas with the curly braces it's much more limited since they just syntax sugar and don't have the power of the capabilities of the block. > If [a.b.c] piped is possible, then [a.b.c] do: [:aStatement| > aStatement value] should be possible to, shouldn't it ? > Or [a.b.c] addStatement: [d] > or [a.b.c] at: 2 put: [e] > > Yes, those are nice additions. Now blocks do become more mailable like lisp code. ;--) Glad to see people with their thinking caps on! Glad to finally see others getting it. Cheers, Peter |
Re: Fear and loathing of the "perification" of Smalltalk
|
|
In reply to this post by pwl
On 05/09/07, Peter William Lount <[hidden email]> wrote:
> No, the changes wouldn't be any more complex than what was done for > curly braces except for adding the parameterization of the passing in of > the collection that you want the results to flow into (including streams). > > To me a. b. c really means "evaluate a then b then c and return the result of c". > For normal default evaluation yes. Problem is, the evaluator is the VM and all it sees is bytecodes. It you want to change the evaluator you have either to change the bytecodes (instrument the block to keep intermediate values) on the fly or make a case statement in the VM. > > - fix the block optimisations, because now they are just sequences of > > expressions with undefined a-priori semantics > > > Could you illuminate more on this, I'm not sure what you mean. Currently the compiler compiles blocks to bytecodes for the statements + a context object. If you want to choose evaluation semantics depending on a message send, then that message send has to recompile the whole block to bytecodes that match the required semantics. All you can do before that message send is store a sequence of expressions. > > (*) just on this point I'd prefer to write something like > > {[a]. [:x| x b]. [:x | x c]} valueAsChain > > > > > What would this evaluate as and how would it evaluate? Would each > element of the collection be evaluated as a block and passed in the > value from the previous element? yes. -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org |
Re: Fear and loathing of the "perification" of Smalltalk
|
|
In reply to this post by pwl
On 05/09/07, Peter William Lount <[hidden email]> wrote:
> The key is in how it's evaluated. With a block that can be chosen at run Changing evaluation means changing bytecode. Bytecode is produced at compile time, so either you produce every version possible and choose at runtime, either you compile nearly nothing and interpret/compile at evaluation time. Both ugly solutions. > time whereas with the curly braces it's much more limited since they > just syntax sugar and don't have the power of the capabilities of the block. But braces have the semantics of "collection of expressions". Blocks have the semantics of "block of code which execution is the standard one, only deferred" > > If [a.b.c] piped is possible, then [a.b.c] do: [:aStatement| > > aStatement value] should be possible to, shouldn't it ? > > Or [a.b.c] addStatement: [d] > > or [a.b.c] at: 2 put: [e] > > > > > Yes, those are nice additions. And I would accept them if they used curlies: {a.b.c} addStatement: [d]. With square braces [a.b.c] it conflicts too much with my intuitive semantics of blocks. -- Damien Pollet type less, do more [ | ] http://typo.cdlm.fasmz.org |
|
|
In reply to this post by Damien Pollet
Damien Pollet wrote:
> On 05/09/07, Peter William Lount <[hidden email]> wrote: > >> No, the changes wouldn't be any more complex than what was done for >> curly braces except for adding the parameterization of the passing in of >> the collection that you want the results to flow into (including streams). >> >>> To me a. b. c really means "evaluate a then b then c and return the result of c". >>> >> For normal default evaluation yes. >> > > Problem is, the evaluator is the VM and all it sees is bytecodes. It > you want to change the evaluator you have either to change the > bytecodes (instrument the block to keep intermediate values) on the > fly or make a case statement in the VM. > Smalltalk implementations use byte codes. > >>> - fix the block optimisations, because now they are just sequences of >>> expressions with undefined a-priori semantics >>> >>> >> Could you illuminate more on this, I'm not sure what you mean. >> > > Currently the compiler compiles blocks to bytecodes for the statements > + a context object. If you want to choose evaluation semantics > depending on a message send, then that message send has to recompile > the whole block to bytecodes that match the required semantics. All > you can do before that message send is store a sequence of > expressions. > Cheers, Peter |
|
|
In reply to this post by Damien Pollet
Damien Pollet wrote:
> On 05/09/07, Peter William Lount <[hidden email]> wrote: > >> The key is in how it's evaluated. With a block that can be chosen at run >> > > Changing evaluation means changing bytecode. Bytecode is produced at > compile time, so either you produce every version possible and choose > at runtime, either you compile nearly nothing and interpret/compile at > evaluation time. Both ugly solutions. > Nonsense, you've locked your brain onto a particular implementation approach before thinking it all through. Blocks simply have a means of evaluation that either returns the last or collects all the values. The rest is done in the primitives. This could be implemented without adjusting how the byte codes are compiled - only statement boundaries would need to be made clear in the even that any optimizations eliminate the boundaries. It depends on how you implement the virtual machine. > >> time whereas with the curly braces it's much more limited since they >> just syntax sugar and don't have the power of the capabilities of the block. >> > > But braces have the semantics of "collection of expressions". Blocks > have the semantics of "block of code which execution is the standard > one, only deferred" > > they should be done that way! Just because it's easy is what leads to perlification! It's the dark road to syntax hell. A key design principle is to have the language the top priority and the virtual machine implementation subordinate to that, not the other way around as you propose. The curly braces solution for Squeak has committed the essential error in the design of Perl, make an easy syntax change to make life for the compiler and virtual machine easy. Unfortunately this brings hell to programmers. >>> If [a.b.c] piped is possible, then [a.b.c] do: [:aStatement| >>> aStatement value] should be possible to, shouldn't it ? >>> Or [a.b.c] addStatement: [d] >>> or [a.b.c] at: 2 put: [e] >>> >>> >>> >> Yes, those are nice additions. >> > > And I would accept them if they used curlies: {a.b.c} addStatement: > [d]. With square braces [a.b.c] it conflicts too much with my > intuitive semantics of blocks. > with the curly braces. There is no need for the curly braces when blocks can do the job. Cheers, Peter |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
On Sep 5, 2007, at 2:01 AM, Peter William Lount wrote:
> Damien Pollet wrote: >> On 05/09/07, Peter William Lount <[hidden email]> wrote: >> >>> The key is in how it's evaluated. With a block that can be chosen >>> at run >>> >> >> Changing evaluation means changing bytecode. Bytecode is produced at >> compile time, so either you produce every version possible and choose >> at runtime, either you compile nearly nothing and interpret/ >> compile at >> evaluation time. Both ugly solutions. >> > Compile time is whenever you wish it to be with Smalltalk. > > Nonsense, you've locked your brain onto a particular > implementation approach before thinking it all through. Blocks > simply have a means of evaluation that either returns the last or > collects all the values. The rest is done in the primitives. This > could be implemented without adjusting how the byte codes are > compiled - only statement boundaries would need to be made clear in > the even that any optimizations eliminate the boundaries. It > depends on how you implement the virtual machine. Well! Read the Blue book if you want to know about the VM. But stop talking about VM, bytecode, compiler and so on if you want to talk about conceptual things. So the question is do we consider block as list of statements or just a chunk of code. Now if you take a look of the functional world you will see that lambda are never consider as a list of statements. If you want a block to be a list of lambda then you make a conceptual mistake. Build a new abstraction if you want to have statements list but don't use the block. Mth > >> >>> time whereas with the curly braces it's much more limited since they >>> just syntax sugar and don't have the power of the capabilities of >>> the block. >>> >> >> But braces have the semantics of "collection of expressions". Blocks >> have the semantics of "block of code which execution is the standard >> one, only deferred" >> >> > Just because the curly braces were simple to implement doesn't mean > that they should be done that way! Just because it's easy is what > leads to perlification! It's the dark road to syntax hell. > > A key design principle is to have the language the top priority and > the virtual machine implementation subordinate to that, not the > other way around as you propose. The curly braces solution for > Squeak has committed the essential error in the design of Perl, > make an easy syntax change to make life for the compiler and > virtual machine easy. Unfortunately this brings hell to programmers. > >>>> If [a.b.c] piped is possible, then [a.b.c] do: [:aStatement| >>>> aStatement value] should be possible to, shouldn't it ? >>>> Or [a.b.c] addStatement: [d] >>>> or [a.b.c] at: 2 put: [e] >>>> >>>> >>>> >>> Yes, those are nice additions. >>> >> >> And I would accept them if they used curlies: {a.b.c} addStatement: >> [d]. With square braces [a.b.c] it conflicts too much with my >> intuitive semantics of blocks. >> > Nonsense. It's very clean and eliminates the need for special > syntax with the curly braces. There is no need for the curly braces > when blocks can do the job. > > Cheers, > > Peter > > |
|
|
In reply to this post by pwl
I can't remember the exact terms anymore but here is the rough syntax of
"these kinds of things" from the first FLEX language ca. 1967.
* means iterate, + means 0 or 1.
Compound ::= begin Body end | ` Body ' Body ::= +{ Variable List} Expression *{ (; | , ) Expression } These subsumed blocks and lists (and lambdas) and were treated as arrays, so they could be indexed. The semantics treated ";" as a clear top of stack operation, and "," as a keep top of stack operation. So the values would get pushed or popped as evaluation proceeded. The compiler counted commas at each level of nesting so it could always make the object out of the values on the stack. Pretty simple and useful, but I didn't think it led to great programming particularly. Wrt Smalltalk (or any language), I think being able to judiciously extend the syntax is a good idea (though often misused), but it needs to be done at the same level as regular programming (so it can be used by any base version of the language). Cheers, Alan |
|
|
In reply to this post by Mathieu SUEN
Mathieu Suen wrote:
> >> Compile time is whenever you wish it to be with Smalltalk. >> >> Nonsense, you've locked your brain onto a particular implementation >> approach before thinking it all through. Blocks simply have a means >> of evaluation that either returns the last or collects all the >> values. The rest is done in the primitives. This could be implemented >> without adjusting how the byte codes are compiled - only statement >> boundaries would need to be made clear in the even that any >> optimizations eliminate the boundaries. It depends on how you >> implement the virtual machine. > > Well! Read the Blue book if you want to know about the VM. > But stop talking about VM, bytecode, compiler and so on if you want to > talk about conceptual things. not polite to tell people how to talk. > > So the question is do we consider block as list of statements or just > a chunk of code. They are both as in Lisp. > Now if you take a look of the functional world you will see that > lambda are never consider as a list of statements. That's because the mainline functional world (haskell, ml, etc...) have a very narrow definition that blinds them and binds them into their paradigm. And in Lisp they are both so your statement is incorrect. > > If you want a block to be a list of lambda then you make a conceptual > mistake. What is the mistake? If you want to limit blocks to a functional style vision that would be a mistake. They have so so much more to offer. > Build a new abstraction if you want to have statements list but don't > use the block. Ah, nope. I'm building it the way that I've described it. I'm simply offering it to the Squeak and Smalltalk communities as a powerful option to enhance Smalltalk with. I invite you to open your eyes wide and see a powerful future for blocks. In fact it's inspired by Lisp - so everything old is new again. Cheers, Peter |
|
|
In reply to this post by Alan Kay
Alan Kay wrote:
> ... > > Wrt Smalltalk (or any language), I think being able to judiciously > extend the syntax is a good idea (though often misused), but it needs > to be done at the same level as regular programming (so it can be used > by any base version of the language). > > Hi, I fully agree with Alan's statement above particularly the first part: "I think being able to judiciously extend the syntax is a good idea (though often misused)". That is exactly the fear that I have with the extensions going on by the various Smalltalk implementations. It creates a highly fragmented language environment. There are already 25+ versions of smalltalk out there. I gather that Smalltalk is following the Unix and Linux model where there are hundreds of versions rather than the Microsoft and Java model where there is just one version. (Ok there are multiple versions of Windows and Java but you get the point). I wonder Alan, if you could, expand on what you mean by "but it needs to be done at the same level as regular programming (so it can be used by any base version of the language)"? Thanks. Peter |
|
|
In reply to this post by pwl
Mathieu Suen wrote:
> On Sep 5, 2007, at 2:40 AM, Peter William Lount wrote: > >> Hi, >> >> Mathieu Suen wrote: >>> >Peter wrote: Oh, well putting it into the virtual machine is the >>> best place for it in my view, but that's an implementation detail. >>> Why is it the best? Performance and flexibility with all the >>> capabilities fully realized. >>> >> >> >>> No. a b and c is statement is not literal. What do you want to put >>> inside the vm. >> The vm would simply need to record the values being produced as the >> result of each statement into a collection. It's the evaluator that >> changes. >> >>> >>> Especially the "." is only for parsing. So block would have a >>> completely different meaning. >> No, the "." is still only for parsing. >>> >>> Suppose you write: >>> >>> [a := 3. >>> a factorial] >>> >>> If the compiler is not to stupid the generate bytecode would look like: >>> >>> pushConstant: 3. >>> storeInTemp:0 >>> send: #factorial >>> >>> So now how would you expect the VM to detect your ".". >>> If you expected such a things then you need to change the Compiler >>> and the block. >>> >> The compiler would need to do something like: >> >> pushConstant: 3. >> storeInTemp: 0. >> add to collection byte code. >> send: factorial. >> add to collection byte code. >> >> The "add to collection byte code", assuming you are using byte codes >> for the code, would be at the end of each statement and would collect >> up the results. >> >> Of course you could also rewrite the block (parse tree) at runtime to >> perform the sequence of add statements much as the current >> implementation does. It really depends on how you want to implement it. >> >> Cheers, >> >> peter >> > > How do you decide when to add the bytecode? > > Mth > > You are still stuck on byte codes eh? That is so 1960's. I invite you into the innovation frame of mind, discard what you think you know about this topic, and open your eyes wide open and imagine a future with powerful blocks. We are just scratching the surface with this one new block feature. I've invented ten more powerful capabilities for blocks and integrated them so they work well. There are many ways to implement the two evaluators for blocks. For example, depending on your byte code set you could have a bit for a flag, or you could duplicate the byte codes with one set for each evaluation type. Or you could get rid of byte codes all together which is the better approach. It's important that a system be as dynamic as possible. You may need to recompile the block at runtime just before it's evaluated if you insist on remaining with the out molded notion of byte codes. But there are other ways. One could simply add a byte code marker for statements as the "add to collection byte code" above illustrated. There are many other ways if you are creative and innovative. The key is being committed to using blocks for this new style of evaluator as well as the old and as well as the other one proposed in this thread, you know, "[ a. b. c] valuesConcurrently. Very powerful stuff as we move into multi core. Since you are the one committed to byte codes, as demonstrated by your remarks, how about you do the thinking on how best to implement it in a system such as squeak. Thanks. Cheers, peter |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by pwl
On Sep 5, 2007, at 2:45 AM, Peter William Lount wrote:
> I wonder Alan, if you could, expand on what you mean by "but it > needs to be done at the same level as regular programming (so it > can be used by any base version of the language)"? I thinks he mean: don't add syntactic rules when you are using your language. Mth |
Re: Fear and loathing of the "perification" of Smalltalk
|
|
In reply to this post by Randal L. Schwartz
On Tue, Sep 04, 2007 at 11:44:43AM -0700, Randal L. Schwartz wrote:
> >>>>> "Peter" == Peter William Lount <[hidden email]> writes: > > Peter> The Perlification of Smalltalk: Curly Braces and the Road to PerlCrypticTalk. > > I respectfully request that you not use Perl as a swear word in my presence. Personally, I find both Smalltalk and Perl to be very appealing. Both have a unifying philosophical point of view. They are quite different and both quite enjoyable. I do recall being surprised that you (Randal) had popped up on the Squeak mailing list, since I associated you with your excellent books on Perl. But on second thought I should not have been surprised, after all TIMTOWTDI :) Dave |
Re: Getting double semi as sequencer harvested.
|
|
In reply to this post by Jon Hylands
On Tue, Sep 04, 2007 at 11:27:43AM -0400, Jon Hylands wrote:
> > ps - since I just turned 40 a couple days ago, that means I've been using > Smalltalk for half my life - pretty cool :-) Dang. I'll be at least 90 before I can say that. |
Re: Getting double semi as sequencer harvested.
|
|
>>>>> "David" == David T Lewis <[hidden email]> writes:
David> On Tue, Sep 04, 2007 at 11:27:43AM -0400, Jon Hylands wrote: >> >> ps - since I just turned 40 a couple days ago, that means I've been using >> Smalltalk for half my life - pretty cool :-) David> Dang. I'll be at least 90 before I can say that. I was able to say that about 5 years ago. :) Not that I was 90, but that I was twice as old as I was when I first compiled a method. :-) I think it was 1982 when I first got my hands on a Magnolia at Tek, executing the ST80 image. If that was 1983, then that would have been only three years ago. I *know* I was executing that before leaving for ServioLogic (later Gemstone) in 84, so that's pretty much a done deal by now, one way or the other. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
Re: Fear and loathing of the "perlification" of Smalltalk
|
|
In reply to this post by pwl
Peter William Lount wrote:
> I wonder Alan, if you could, expand on what you mean by "but it needs to > be done at the same level as regular programming (so it can be used by > any base version of the language)"? Isn't that obvious? When you add the method #frobler to Object you extend the language. And at the same level as regular programming. For example, one could consider implementing operators that way, say in a Prolog style, priority driven way: Object>>plus: anObject <operator: #+ type: #yfx priority: 500> Object>>minus: anObject <operator: #- type: #yfx priority: 500> This implements all the semantics as plain messages but leaves operators as syntactic sugar on top of them. The compiler would translate "a + b" into "a plus: b" and the decompiler -if it knows about the plus operator in your system- would decompile as #+. If it didn't know about it, it would decompile as #plus:. Your code would depend on the "PlusMinus" package that other people have to load (since it contains the operator definitions). Etc. It's pretty straightforward. Cheers, - Andreas |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |