Self-interest April 2020

self-interest@lists.selflanguage.org

14 participants
12 discussions

ideal gas and other self examples
by Stephen De Gabrielle 29 Apr '20

29 Apr '20

Hi, I took a copy of the ideal gas self code about 6 years ago but I can't remember where I found it. Does anyone know where this and other examples are located? Kind regards Stephen NB My copy https://github.com/spdegabrielle/gasTank

1 0

self.js
by Steve Dekorte 24 Apr '20

24 Apr '20

I’ve been having fun trying out Squeak JS: https://squeak.js.org/ Would something like this be possible with Self? Steve

2 1

Concurrent-constraint Logic Programming
by Jack Waugh 24 Apr '20

24 Apr '20

Thanks for the reference. I hadn't seen UFO, but I had been aware of ToonTalk and Janus and the actor model. On Thu, Apr 23, 2020 at 3:00 PM Mario Wolczko mario-at-wolczko.com |pub yahoo| <> wrote: > Have you read about UFO (United Functions and Objects) by John Sargeant, > c.1992? It wasn’t prototype-based, but your email otherwise brought it to > mind. There’s an overview paper here: > > https://www.semanticscholar.org/paper/United-Functions-and-Objects%3A-an-Ov… > <https://www.semanticscholar.org/paper/United-Functions-and-Objects:-an-Over…> > and several other papers can be found. > > There was a spate of concurrent OO logic language papers in the late > 80s/early 90s. A skim of OOPSLA proceedings from that era should turn up > many. And before that there was ThingLab (in Smalltalk). > > >

1 0

Fwd: Toward Declarative Programming
by Jack Waugh 23 Apr '20

23 Apr '20

As I understand it, the Self language uses imperativity all the way down to its fundament. In particular, I believe the usual (and only?) way to set up an object is to clone an existing one (the prototype) and then mutate one clone. I don't see anything about the language, nor more generally about a classless outlook, that would light the way toward creating a good declarative language. Am I missing something? Jack WAUGH

4 5

Concurrent-constraint Logic Programming
by Jack Waugh 23 Apr '20

23 Apr '20

I brought up in this forum the subject of the good or poor fit between, on the one hand, Self's syntax and other principles, and on the other hand, declarative programming. I want to narrow the topic to a specific sort of declarative programming: concurrent-constraint logic programming. I start to imagine a Self-influenced concurrent-constraint language. There could still be objects and slots, and a slot could still contain code or data. But the code instead of representing fundamentally an imperative procedure that can perpetrate side effects but in either event returns a value (a "function" in the Fortran sense but not necessarily in the mathematical sense), I'm thinking that the code would receive a logical interpretation. If the method is called, its sentences would be held to be true (over the arguments, including the receiver), and the order of evaluation or elaboration or execution of the sentences could not matter. The method would execute atomically (over those arguments), or not at all. Execution would never use a stack. Rather, it would use a trampoline and could defer tasks by putting them in the trampoline's task queue. Each task would represent an inferred truth over a collection of arguments. In the brand of concurrent-constraint execution I am thinking about, it would be desirable to be able to exclude, through rules that could be applied to the code before it is admitted into the system, the possibility of the system ever arriving at a logical contradiction concerning the data or events it processes from the real world. If logical contradiction could happen at run time, it might have to result in a major subsystem taking a dive. I am not contemplating here something like Prolog or Icon, where contradiction is part of the normal way of life of programming and the conditional tests are courting contradiction and contradiction is the normal way of representing falsity. I call those "succeed-fail" languages. ( | parent* = something. b. combobulate: a = ( a ifTrue: [b: 'It's true!'] False: [b: 'No, it isn't!'] ). | ) Now if we read ifTrue:False: with its usual meaning, there is no problem here. The value of b will be determined if combobulate: is called. But a tool for static analysis does not know whether "a" implements a perverted version of ifTrue:False that executes both branches. In this case, we run into a logical contradiction, because "b" gets two distinct values, which can't be allowed in a declarative world. As Leonard Susskind said, if a thing is one thing, it is definitely not the other.

3 2

Deriving a Declarative Language from the Self Language
by Jack Waugh 22 Apr '20

22 Apr '20

I'm not sure whether the following idea comports with implementability and who knows what other considerations, but it occurs to me that we could have: foo bar: (baz bletch: 2). would be considered to be calling bletch: in a function-call context, and in this context if | bletch | were a variable declaration in the pattern from which baz is derived, then bletch: 2 would mean give me another object just like baz but with 2 substituted in for the value of bletch. But having a command baz bletch: 2. by itself as a command like that would mean we are callling bletch: in a procedure-call context as contrasted with a function-call context, and the meaning under the declaration | bletch | in this context could be that we are inferring that the value of bletch on baz is 2; we are constraining the value to 2 on the grounds that we only got to this call because of sufficient tests that conditions hold that imply this.

1 0

Deriving a Declarative Language from the Self Language
by Jack Waugh 22 Apr '20

22 Apr '20

Sorry I started this thread in the wrong place in the hierarchy (as it appears in the archive). Thank you, Adam Spitz for your philosophical response. In the realm of declarative programming, I have been interested in concurrent constraints. I envision using a combination of language and execution environment where the language proper would be purely declarative but the environment would provide access to such facilities as fall outside declarativity but are needed or desired for dealing with the outside world. I'm thinking that such an approach might not clash badly with the syntax of Self and maybe some of the other ideas related to Self. The "slots" in an "object" might consist of a fixed label paired with a "variable", which is a thing that could exist for part of its history as having unknown value, but a procedure/method could constrain it to have a particular value. Trying to constrain it in logically inconsistent ways would be an error. I suppose part of the source of objects having slots that haven't yet been constrained would be the aforementioned runtime environment. Maybe an operation to create such an object would require at least these two inputs: a pattern or prototype to give the object its known behaviors, and an "oracle" as described by Burton and Lennart; this latter would come from a stream of arbitrarily many oracles as needed supplied by the magic runtime environment. On Wed, Apr 22, 2020 at 8:38 AM Adam Spitz wrote: > I agree that "copy and mutate" sounds like it might not be compatible with > declarative programming, but I think there are deeper psychological > principles that make Self worth understanding even if you don't want > imperative programming. > > I don't know whether you've heard the prototype spiel before, and Dave and > various others here can do it better than I can, but: > > Part of the motivation behind prototype-based languages is that when human > beings come up with categorization systems that feel intuitive, they > usually don't really look like "here are the properties that are shared by > every member of this category"; they look much more like "here are some > properties that are typically shared by the more-central members of this > category, most of the time; membership in the category is fuzzy, and varies > depending on how similar the thing is to the central examples of the > category; we define things by describing how they're different from other > things." (George Lakoff makes the case for this in Women, Fire, and > Dangerous Things.) > > For example, here are some observations about the way humans categorize > things: > > - A robin is a better example of a bird than an ostrich is. (Membership > gradience - some examples are more central than others, and people > more-readily identify the central examples as belonging to that category.) > - Most humans have ten fingers, but a few don't, and they probably still > qualify as human. (Family resemblances - not all properties are shared.) > - If someone shows you a picture of a tabby cat and asks you what it is, > you say "cat", not "animal" or "tabby". (The most cognitively-basic part of > the abstraction hierarchy is somewhere in the middle, rather than the top > or bottom.) > - etc. > > (Of course, human beings also came up with the more-rigid categorization > systems that are used in most of mathematics, and those systems still > sorta-kinda count as categorization systems, despite not having all of the > properties that the more-typical categorization systems have. ;)) > > I'm not saying that you *can't* find some way to represent those kinds of > qualities in a class-based language like Smalltalk or a type-theory-based > language like Haskell; I'm just saying that these considerations are (as > far as I've seen) not even really on the radar of people who talk about > those languages. (Which isn't to say that Self does it perfectly. I don't > think Self - or any other prototype-based language that I know of - fully > captures the flavour of the categorization model that Lakoff describes. But > Self's "you make new things by copying and modifying existing things" is > meant to be a step in that direction. It's something that the Self people > have spent some time thinking about.) If you buy Lakoff's theory, there's > something in human psychology that isn't a good fit for the kinds of rigid > categorization systems used in existing declarative languages like Haskell. > > With that said, I've spent the past few years learning about Haskell and > functional programming and type theory and category theory and proofs and > various other things that I used to consider icky, and I like it very much. > I'm convinced that it's usually a very good idea to avoid imperativeness > and mutation as much as possible, and I'm convinced that there's a huge > amount of value in the kinds of mathematically-precise abstractions > (functors, monads, algebraic data types, etc.) that are used in those kinds > of languages, and I'm convinced that type systems are much much more-useful > and less-awful than I believed back when the only typed languages I knew > were C++ and Java. I wouldn't be happy going back to a dynamically-typed > imperative language like Self (though I do desperately miss the Self > environment). But I think there are some insights about human psychology > that the Self people understand better than the Haskell people. > > I'm not sure about this part, but I don't think those psychological > insights are fundamentally incompatible with declarative programming; I > just think it's the kind of thing that the declarative-programming world > hasn't spent a lot of time focusing on. So, yes, I think there's a lot in > Self's classless outlook that could light the way toward creating a better > declarative language. > > > > > On Tue, Apr 21, 2020 at 11:52 PM Jack Waugh <tzh9741mq402(a)sneakemail.com> > wrote: > >> As I understand it, the Self language uses imperativity all the way down >> to its fundament. In particular, I believe the usual (and only?) way to set >> up an object is to clone an existing one (the prototype) and then mutate >> one clone. I don't see anything about the language, nor more generally >> about a classless outlook, that would light the way toward creating a good >> declarative language. Am I missing something? >> >> Jack WAUGH >> >

1 0

Self on MacOS
by Steve Dekorte 21 Apr '20

21 Apr '20

Is there a build of Self for MacOS Catalina (which is now 64bit only)? Steve

5 5

Re: [Self-interest] slot pairs?
by kjx 19 Apr '20

19 Apr '20

I certainly understood the phrase as soon as it was mentioned on the list; and then started to recall things about "naked assignment slots that weren't supported. Can't remember too many more details about that --- basically could a naked assignment slot assign an immutable slot reached by delegation... But then, I remembered the greatest legacy of the Self Project: Javascript! (argh!!) OK: the second greatest legacy, Google. "slot pair" is used in - Chapter 4 of Craig's 1992 PhD thesis - the ECOOP '95 retrospective "Programming as an Experience" - the HOPLIII (2007) retrospective "Self" - the 2014 KORZ paper so can we all agree to blame Craig, even if it's actually Dave's fault? James https://www.google.com/search?client=safari&rls=en&q=%22slot+pair%22+self+l… > On 18/04/2020, at 17:40PM, Randy <randy.smith(a)gmail.com> wrote: > > I’m sure you’re right about that Dave .. for practical reasons, it was embedded in the code somewhere. > > —Randy > > >> On Apr 17, 2020, at 7:45 PM, David Ungar <ungar(a)mac.com> wrote: >> >> At the very least, there was *something* in the mirror and likely VM code so that when you removed “a”, “a:” was also removed (assuming it was an assignment slot). >> >>> On Apr 17, 2020, at 2:53 PM, Randy <randy.smith(a)gmail.com> wrote: >>> >>> Steve— >>> >>> Hey maybe you could grep through the documentation for that term? But again, my memory is the concept is not formally defined in Self. Dave may have used it in the code for mirrors, but in discussing language semantics, or program design, or object structure, there was no set aside special name. >>> >>> In the original Self group, if anyone had said “the slot pair for X” while chatting about some self object, there is a fair chance the listener may have understood the intent. But depending on the conversational context, the term could also be confusing I suppose. (It might mean the x slot in an object together with an x slot in a parent, if you were talking about inheritance and overriding.) >>> >>> —Randy >>> >>> >>>>> On Apr 17, 2020, at 1:57 PM, Steve Dekorte <steve(a)dekorte.com> wrote: >>>> >>>> >>>> Hi all, >>>> >>>> Glad to see this list is still active. >>>> I have a question about slot terminology: >>>> >>>> Self referred to a given property (object table key/value ) as a “slot”. >>>> So, a Point might have a “x" getter slot and an “x:" setter slot. >>>> Was there any name you for the set of slots related to a property (in the Point case, the set of “x” and “x:” slots)? >>>> >>>> David wasn’t sure but thought this might have been called a “slot pair” and used in mirrors. Is that right the correct term? >>>> >>>> Steve >>>> >>>> _______________________________________________ >>>> Self-interest mailing list >>>> Self-interest(a)lists.selflanguage.org >>>> http://lists.selflanguage.org/mailman/listinfo/self-interest >>> _______________________________________________ >>> Self-interest mailing list >>> Self-interest(a)lists.selflanguage.org >>> http://lists.selflanguage.org/mailman/listinfo/self-interest >> > _______________________________________________ > Self-interest mailing list > Self-interest(a)lists.selflanguage.org > http://lists.selflanguage.org/mailman/listinfo/self-interest >

5 5

Full email archive now online
by Russell Allen 18 Apr '20

18 Apr '20

Hi all, As part of the change to the new mailing list, Tobias has added to the archive emails collected by Jecel dating back to 1990. This means that if you go to the site: http://lists.selflanguage.org/pipermail/self-interest/ <http://lists.selflanguage.org/pipermail/self-interest/> there is an email archive of discussions literally going back 30 years. Cheers Russell

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest April 2020