Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If-statements in Smalltalk (2008)

pozorvlak.livejournal.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: If-statements in Smalltalk (2008)

#22

Post by vertex-four »

pg314 wrote: post #20

Since if-statements are built out of blocks and message sending, you can easily do some cool things. One of them is building up an abstract syntax tree (AST) of an expression without parsing that expression. E.g. suppose you want to build up an AST of the statement (x Instead of starting with an x of type Number, you would start with an object of type ASTVariable, that responds to the message As an sexp: (ASTIfStatem…

Something quite similar is used in some RethinkDB drivers, especially around lambdas. For example:

    r.table('users').filter(lambda user:
        user["age"] == 30
    ).run(conn)
The lambda there is actually only ever called once, on the client-side, with an equivalent of your ASTVariable, to generate an AST of the comparison which is sent to the server and processed there.

Re: If-statements in Smalltalk (2008)

#23

Post by vidarh »

vbit wrote: post #10

This applies to loops as well. Numbers are objects that accept the `timesRepeat:` message: 10 timesRepeat: [ n := n*2 ]. Not only that, you can send messages to blocks, to implement loops. [ n

Compare to Ruby:

    10.times { n = n * 2 }
The latter isn't possible "out of the box", but easy enough to implement:

    class Proc
        def whileTrue; yield while self.call; end
    end

    # And use:
    n = 1
    ->{ n
Ruby syntax does get in the way of some of the more succint ways of defining control structures in Smalltalk, but the above shows some of the Smalltalk heritage of Ruby quite well, I think (though, while "10.times" is fairly idiomatic Ruby, implementing constructs like the one below certainly is not).

Re: If-statements in Smalltalk (2008)

#24

Post by philippeback »

dws wrote: post #7

The explanation is almost correct, but misses a tiny, but interesting detail. Subclasses of Boolean do implement #ifTrue: and #ifFalse:, wich each take a block (a no-argument function) as an argument. But they also implement #ifTrue:ifFalse:, which takes two blocks as arguments. In a a single message (#ifTrue:ifFalse:) is sent to the boolean that results from evaluating 'a Coming from Pascal and C, seeing that IF/ELS…

VMs are usually inlining those message sends, which makes them fast.

Re: If-statements in Smalltalk (2008)

#26

Post by pozorvlak »

dws wrote: post #7

The explanation is almost correct, but misses a tiny, but interesting detail. Subclasses of Boolean do implement #ifTrue: and #ifFalse:, wich each take a block (a no-argument function) as an argument. But they also implement #ifTrue:ifFalse:, which takes two blocks as arguments. In a a single message (#ifTrue:ifFalse:) is sent to the boolean that results from evaluating 'a Coming from Pascal and C, seeing that IF/ELS…

Thanks! I've now fixed this in the post.

Re: If-statements in Smalltalk (2008)

#27

Post by pozorvlak »

pg314 wrote: post #20

Since if-statements are built out of blocks and message sending, you can easily do some cool things. One of them is building up an abstract syntax tree (AST) of an expression without parsing that expression. E.g. suppose you want to build up an AST of the statement (x Instead of starting with an x of type Number, you would start with an object of type ASTVariable, that responds to the message As an sexp: (ASTIfStatem…

That's really cool! I imagine that would allow you to do concolic testing easily? https://en.wikipedia.org/wiki/Concolic_testing

Re: If-statements in Smalltalk (2008)

#28

Post by pozorvlak »

RangerScience wrote: post #16

Fascinating. An amazing point about design patterns, and yet... Declarative statements are a pattern in ruby - you see them everywhere (`attr_accessor`). They're library code - you're intended to write them. I can't imagine trying to write ruby without that pattern, and I can't imagine them not being a design pattern. Similarly - the MVC of Rails. The lines get way fuzzier, but you still might try to draw similar lin…

I was really trying to make a narrower point here - that there is a reasonable way to distinguish "part of the language" from "part of the (standard) library" - but I'll bite :-)

attr_accessor, as it happens (http://ruby-doc.org/core-2.0.0/Module.html#method-i-attr_acc...) is implemented in C code, but one could implement it in Ruby, so I'd count it as part of the (standard) library, and creating accessors is just using a library method. In, say, Java setters and getters have to be written by hand (or autogenerated by some external system like an IDE), so they're a pattern. On the other hand, the way Ruby translates `foo.bar = 3` into a call to `foo`'s `bar=` method is not alterable by user code, so it's part of the language.

MVC in Rails is an interesting case. You have to create new classes according to the pattern (either by hand or using `rails generate`), but there's also some library support in the form of Model and Controller classes you're expected to inherit from, and which handle much of the View/Controller plumbing for you. I'd say it's still a pattern, though.

Re: If-statements in Smalltalk (2008)

#30

Post by pozorvlak »

brudgers wrote: post #4
ColinWright wrote: post #3

Earlier quoted context omitted.

Do you think it's now invalid? Do you think anything has changed? I'd be interested to hear of any news that you think would update this.

Not at all, and that's why I upvoted it. I mentioned the date because it is traditional in titles. Here it might put comparisons to ES9 and complaints about display on the iPhone 10s in context (I'm optimistic). Pessimistically, it might give fair warning that hyperlinks from the page 404.

Thanks! I've now updated the post to reflect some corrections here, and to point out the 404ing link.
Post reply on HN