From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.user Subject: Re: A couple of questions about goops method parameters Date: Sun, 7 Sep 2014 00:57:02 +0800 Message-ID: References: <1409905923.9245.5.camel@Renee-desktop.suse> <871trpridm.fsf@izanagi.i-did-not-set--mail-host-address--so-tickle-me> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0160b79a90e3760502687916 X-Trace: ger.gmane.org 1410022649 26750 80.91.229.3 (6 Sep 2014 16:57:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Sep 2014 16:57:29 +0000 (UTC) Cc: Guile User , David Thompson , Carlos Pita To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Sep 06 18:57:24 2014 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XQJIf-0004tJ-3z for guile-user@m.gmane.org; Sat, 06 Sep 2014 18:57:21 +0200 Original-Received: from localhost ([::1]:35779 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQJIe-0000uN-Nw for guile-user@m.gmane.org; Sat, 06 Sep 2014 12:57:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQJIV-0000uG-ID for guile-user@gnu.org; Sat, 06 Sep 2014 12:57:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XQJIU-0002GK-10 for guile-user@gnu.org; Sat, 06 Sep 2014 12:57:11 -0400 Original-Received: from mail-la0-x233.google.com ([2a00:1450:4010:c03::233]:43901) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XQJIT-0002GB-K7 for guile-user@gnu.org; Sat, 06 Sep 2014 12:57:09 -0400 Original-Received: by mail-la0-f51.google.com with SMTP id gi9so3511694lab.38 for ; Sat, 06 Sep 2014 09:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YaWYJuELHnNqV8cwPvoxg7DVALkcnu//xPLCNFu40ng=; b=AEy8Otgmy9yWW0TQKPfcmQahYEfxXBYA2+KAYMI7s5egPgZd2axpSz1Webgq5awRVZ Z0yfFP0xfdDZ4mfUeQLVUFjishzdoYcj/k8gjFlDXdEuinQM0rN7UqrUeQZucZxCleWq l1+H2+Uranztu3A3YLJWDd1GMt+neYCTdZWjfTUMPCdgAMkrvXPs/97arpvPXN4Tcpro C08M6TCrlpldl1loq39UmlQ0BqrLQiKdE/az33xLyp50MezTselu1wrcDijIuHYeWxF2 axfTdM7nJXB3xMhy/xokwbRhEKZo6Nes9bWDWQT7bDGKP5ZNTB+KpC3BDmcxGV9CEhI+ us+A== X-Received: by 10.152.28.230 with SMTP id e6mr18836980lah.62.1410022622944; Sat, 06 Sep 2014 09:57:02 -0700 (PDT) Original-Received: by 10.152.122.99 with HTTP; Sat, 6 Sep 2014 09:57:02 -0700 (PDT) Original-Received: by 10.152.122.99 with HTTP; Sat, 6 Sep 2014 09:57:02 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::233 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:11478 Archived-At: --089e0160b79a90e3760502687916 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 2014=E5=B9=B49=E6=9C=886=E6=97=A5 =E4=B8=8A=E5=8D=884:10=E4=BA=8E "Panicz M= aciej Godek" =E5=86=99=E9=81=93=EF=BC=9A > > : > >> http://elm-lang.org/learn/What-is-FRP.elm > >> > >> Using FRP, we can model with mutable state in a pure, functional way. > > OTOH, when you take a look at the example code (Mario), you can trace > the notion of objects. E.g. > mario =3D { x =3D 0, y =3D 0, vx =3D 0, vy =3D 0, dir =3D "right" } > > What else is that, if not an object? > "Well, it's a structure", one could say -- because it has no methods. > However, this is just what the most rudimentary GOOPS objects are -- a > named tuple (provided that you use no virtual slots). I think that it > is a big problem of Scheme, that it does not have any noncontroversial > and commonly accepted way for creating named tuples. > Doesn't assoc-list fill the gap? > Furthermore, instead of using explicit side effects, as one would > normally do, the Mario example first defines a step function, and > calls "foldp step mario input". Although I do appreciate efforts like > in "How to Design Worlds" book or "Introduction to Systematic Program > Design" course, to avoid explicit mutation (because as SICP shows, it > complicates the model of computation), I don't see so many benefits of > avoiding mutation in complex realtime systems. > I partly agree with you. For stateless makes things complex. Yes, it could be complex. But, no, it depends on need and scenario. The advantage of stateless is to provide a more reliable and understandable system to users and maintainers. If your system is constrained by hard realtime need, go ahead with side-effect, it's cool. But most of the time, it's not the story from reasonable users. If you doubt stateless party exaggerated the truth, I'll recommend this paper: <> > Actually, when I look at the Mario example, I have a feeling that the > code would be much cleaner and easier to follow if it was written in a > more traditional imperative/callback style. It's fine if you think imperative is still cool in FP, me too, since most people living in non-FP land. But if you're expecting imperative way in FP land rather than learning and trying it in FP way, why not choose non-FP lang for it? :-) --089e0160b79a90e3760502687916 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2014=E5=B9=B49=E6=9C=886=E6=97=A5 =E4=B8=8A=E5=8D=884:10=E4=BA=8E "Pan= icz Maciej Godek" <godek.= maciek@gmail.com>=E5=86=99=E9=81=93=EF=BC=9A
>
> <dthompson2@worcester.e= du>:
> >> http://= elm-lang.org/learn/What-is-FRP.elm
> >>
> >> Using FRP, we can model with mutable state in a pure, functio= nal way.
>
> OTOH, when you take a look at the example code (Mario), you can trace<= br> > the notion of objects. E.g.
> mario =3D { x =3D 0, y =3D 0, vx =3D 0, vy =3D 0, dir =3D "right&= quot; }
>
> What else is that, if not an object?
> "Well, it's a structure", one could say -- because it ha= s no methods.
> However, this is just what the most rudimentary GOOPS objects are -- a=
> named tuple (provided that you use no virtual slots). I think that it<= br> > is a big problem of Scheme, that it does not have any noncontroversial=
> and commonly accepted way for creating named tuples.
>

Doesn't assoc-list fill the gap?

> Furthermore, instead of using explicit side effects, as= one would
> normally do, the Mario example first defines a step function, and
> calls "foldp step mario input". Although I do appreciate eff= orts like
> in "How to Design Worlds" book or "Introduction to Syst= ematic Program
> Design" course, to avoid explicit mutation (because as SICP shows= , it
> complicates the model of computation), I don't see so many benefit= s of
> avoiding mutation in complex realtime systems.
>

I partly agree with you. For stateless makes things complex.= Yes, it could be complex.
But, no, it depends on need and scenario. The advantage of stateless is to = provide a more reliable and understandable system to users and maintainers.=
If your system is constrained by hard=C2=A0 realtime need, go ahead with si= de-effect, it's cool. But most of the time, it's not the story from= reasonable users.
If you doubt stateless party exaggerated the truth, I'll recommend this= paper:=C2=A0<<Out of the tar pit>>

> Actually, when I look at the Mario example, I have a fe= eling that the
> code would be much cleaner and easier to follow if it was written in a=
> more traditional imperative/callback style.

It's fine if you think imperative is still cool in FP, m= e too, since most people living in non-FP land.
But if you're expecting imperative way in FP land rather than learning = and trying it in FP way, why not choose non-FP lang for it? :-)

--089e0160b79a90e3760502687916--