suzuki

Joined 12 years ago

Karma
176
Submissions
74
Member since
Jan 25
https://github.com/nukata
View on Hacker News

Recent submissions

Comment · 4 years ago
> If you have an interface with a single method, or something with a single varying piece of behavior, please strongly consider accepting a function instead.

Agreed. And if you prefer methods to functions, you can define methods on such a function type! In my LINQ in Go (https://github.com/nukata/linq-in-go), I define a higher order function type:

  type Enumerator[T any] func(yield func(element T))
and several methods on it, for example,

  // Where creates an Enumerator which selects elements by appling
  // predicate to each of them.
  func (loop Enumerator[T]) Where(predicate func(T) bool) Enumerator[T] {
        return func(yield func(T)) {
                loop(func(element T) {
                        if predicate(element) {
                                yield(element)
                        }
                })
        }
  }
Naturally, if you need another type parameter for a method, you must define it as a function. For example,

  // Select creates an Enumerator which applies f to each of elements.
  func Select[T any, R any](f func(T) R, loop Enumerator[T]) Enumerator[R] {
        return func(yield func(R)) {
                loop(func(element T) {
                        value := f(element)
                        yield(value)
                })
        }
  }
Now, with the function which converts a slice to an Enumerator,

  // From creates an Enumerator from a slice.
  func From[T ~[]E, E any](x T) Enumerator[E] {
        return func(yield func(E)) {
                for _, element := range x {
                        yield(element)
                }
        }
  }
you can write the following:

  seq := Select(func(e int) int { return e + 100 },
        From([]int{
                7, 8, 9,
        })).Where(func(e int) bool {
        return e%2 != 0
  })
  seq(func(e int) {
        Println(e)
  })
  // Output:
  // 107
  // 109
Comment · 5 years ago
Comment · 5 years ago
From a Japanese perspective, it also sounds very unlikely. Go with UTF-8 strings is successful nowadays in Japan.
Comment · 5 years ago
I agree with you. I wish Python 3 had strings as byte sequences mainly in UTF-8 as Python 2 had once and Go has now. Then things would be kept simple in Japan. Python 3 feels cumbersome. To handle a raw input as a string, you must decode it in some encoding first. It is a fragile process. It would be adequate to treat the input bytes transparently and put an optional stage to convert other encodings to UTF-8 if necessary.
Comment · 6 years ago
Comment · 6 years ago
Comment · 6 years ago
Now the abstract sequence type of "LINQ in Go" https://github.com/nukata/linq-in-go can be written as

  type Enumerator(type T) func(yield func(element T))
and the "Select" method can be written as

  func (loop Enumerator(T)) Select(f func(T) T) Enumerator(T) {
        return func(yield func(T)) {
                loop(func(element T) {
                        value := f(element)
                        yield(value)
                })
        }
  }
You can call this method with type-safety as follows. Yay!

  func main() {
        squares := Range(1, 3).Select(func(x int) int { return x * x })
        squares(func(num int) {
                fmt.Println(num)
        })
  }
  // Output:
  // 1
  // 4
  // 9
See https://go2goplay.golang.org/p/b0ugT68QAy2 for the complete code.

And, for generality, you should write the method actually as follows.

  func (loop Enumerator(T)) Select(type R)(f func(T) R) Enumerator(R) {
        return func(yield func(R)) {
                loop(func(element T) {
                        value := f(element)
                        yield(value)
                })
        }
  }
However, you will get the error message then:

  type checking failed for main
  prog.go2:17:33: methods cannot have type parameters
According to https://go.googlesource.com/proposal/+/refs/heads/master/des... this seems an intended restriction:

> Although methods of a generic type may use the type's parameters, methods may not themselves have additional type parameters. Where it would be useful to add type arguments to a method, people will have to write a suitably parameterized top-level function.

> This is not a fundamental restriction but it complicates the language specification and the implementation.

For now, we have to write it as https://go2goplay.golang.org/p/mGOx3SWiFXq and I feel it rather inelegant. Good grief

Comment · 6 years ago
You are absolutely right. I have written Scheme interpreters in both languages. Compare https://github.com/nukata/little-scheme-in-ruby/blob/v0.3.0/...

  # Cons cell
  class Cell
    include Enumerable
    attr_reader :car
    attr_accessor :cdr

    def initialize(car, cdr)
      @car = car
      @cdr = cdr
    end

    # Yield car, cadr, caddr and so on, à la for-each in Scheme.
    def each
      j = self
      begin
        yield j.car
        j = j.cdr
      end while Cell === j
      j.nil? or raise ImproperListException, j
    end
  end # Cell
and https://github.com/nukata/little-scheme-in-crystal/blob/v0.2...

  # Cons cell
  class Cell < Obj
    include Enumerable(Val)

    getter car : Val            # Head part of the cell
    property cdr : Val          # Tail part of the cell

    def initialize(@car : Val, @cdr : Val)
    end

    # Yield car, cadr, caddr and so on, à la for-each in Scheme.
    def each
      j = self
      loop {
        yield j.as(Cell).car
        j = j.as(Cell).cdr
        break unless Cell === j
      }
      raise ImproperListException.new(j) unless j.nil?
    end
  end # Cell
and they will make the point clear. Ruby and Crystal are different languages, but you can translate your code from Ruby to Crystal line by line fairly easily.

For the performance boost, see https://github.com/nukata/little-scheme/tree/v1.3.0#performa... which shows times to solve 6-Queens on a meta-circular Scheme as follows:

* Crystal 0.34.0: crystal build --release scm.cr: 2.15 sec.

* Crystal 0.34.0: crystal scm.cr: 9.88 sec.

* Ruby 2.3.7: ruby scm.rb: 84.80 sec.

Compiled (and complex enough) Crystal code runs 39 times faster than the equivalent Ruby code in this case.

Comment · 6 years ago
I totally agree with you. I hope we still have a chance to do it well with PyPy.
Comment · 6 years ago
I have just updated my Scheme interpreter in Crystal (https://github.com/nukata/little-scheme-in-crystal), which I used on the above benchmark test, along to Crystal 0.34.

The release notes of Crystal 0.34 say "Having as much as possible portable code is part of the goal of the std-lib. One of the areas that were in need of polishing was how Errno and WinError were handled. The Errno and WinError exceptions are now gone, and were replaced by a new hierarchy of exceptions." So I have modified

    rescue ex: Errno
      raise ErrorException.new(ex.message, NONE) if ex.errno == Errno::EPIPE
to

    rescue ex: IO::Error
      raise ErrorException.new(ex.message, NONE) if ex.os_error == Errno::EPIPE
though it is still dependent on POSIX. >_<
Comment · 6 years ago
Comment · 6 years ago
Comment · 6 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton