Re: Terseness, precedence, deprogramming (was Re: [fonc] languages)
On Sun, Jun 5, 2011 at 8:13 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Another approach I think is really cool is actually just using mathematical notation as one representation of what's otherwise basically an s-expr, in which case I think one is having some cake and eating it too. I've been playing with Mathematica a bit, which seems to do some of that. Kind of like flipping between the piano roll and the notation view in a music program. I also think their big algorithm library is a really lovely idea... If it doesn't necessarily separate meaning from optimization, it at least seems like it could help separate math from glue and plumbing which would just be a godsend in my work, where it often feels like I have to read-between-the-lines to find an algorithm in a piece of code I'm looking at. You would like Fortress: http://labs.oracle.com/projects/plrg/faq/NAS-CG.pdf Here is an example of runnable Fortress code: http://labs.oracle.com/projects/plrg/faq/NAS-CG.pdf (There is also an ASCII-only syntax for us luddites.) --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: Electrical Actors?
I explored this idea a bit once upon a time in the context of Java: http://cscott.net/Publications/design.pdf The bibliography cites most of the related work I know about. --scott -- ( http://cscott.net ) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: Electrical Actors?
Ooooh, this looks shiny. I must admit having a taste for the stochastic. Reading. Thank you! Nope... drat. Clicking to request access to the document instead. On Jun 5, 2011, at 10:00 PM, Max OrHai max.or...@gmail.com wrote: You might get a kick out of this toy model I made to demonstrate how a mesh (or cloud) of minimal hardware actors can work together to compute. It's the latest in a series of explorations of the particle / field concept... http://cs.pdx.edu/~orhai/mesh-sort I think there's a lot that can be done with fine-grained homogeneous self-contained hardware in quantity, and I may get around to building a poor man's Connection Machine out of a bucketful of microcontrollers one of these days. The AVR is quite a capable machine for $5 apiece! -- Max (big snip for bandwidth)___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: Electrical Actors?
Below:) On Jun 5, 2011, at 11:19 PM, C. Scott Ananian csc...@laptop.org wrote: I explored this idea a bit once upon a time in the context of Java: http://cscott.net/Publications/design.pdf The bibliography cites most of the related work I know about. --scott Reading it now -- thanks for sharing this. I remember feeling so fascinated when I heard people talking about JavaOS on a chip; while I was aware of people jamming whole operating systems into ROM, the idea of an OS written mostly in a high level language by itself was completely new to me then (I was in highschool, I had only just secured Internet access for the first time) and it was just so compelling... You can do that?? was what I remember thinking, wait, how's that work... Oh I don't even care, forget about this manual memory management thing then! May I have a triple tall mocha with no whip? And do you do those in bulk orders? It's a shame that it took me so many years to find Smalltalk. Sometimes I wish I could go back in time just to point myself at things. I may not have listened to future-me then, though, so I suppose the real lesson is to remember that I probably don't know anything of import even now, and that the best ideas I've got presently are likely to find hard judgement in my own eventual hindsight. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] languages
I've heard of an IDE called VisualAge (I think?) that was written in Smalltalk but could parse and to a degree reason about other languages, but I've never seen it. Have you looked for that thing, or was it just not so great? On Jun 5, 2011, at 11:55 PM, BGB cr88...@gmail.com wrote: On 6/5/2011 11:03 PM, C. Scott Ananian wrote: On Sun, Jun 5, 2011 at 8:35 PM, BGB cr88...@gmail.com wrote: I would personally like to see an IDE which was: more-or-less language neutral, to what extent this was practical (more like traditional standalone editors); not tied to or hard-coded for particular tools or build configurations (nearly everything would be actions tied to high-level scripts, which would be customizable per-project, and ideally in a readily human-editable form); not being tied to a particular operating system; ... This is Eclipse. Granted, it's an IDE which is designed-by-committee and hard to love, but it answers all of your requirements. --scott I don't believe Eclipse is it, exactly... it handles multiple languages, yes, and can be used with multiple operating systems, and supports multiple compiler backends, ... however, AFAIK, pretty much all of the logic is written in Java-based plugins, which is not ideal (and so, essentially the logic is tied to Eclipse itself, and not to the individual projects). I was imagining something a little different here, such as the project control files being more like Makefiles or Bash-scripts, and so would be plain-text and attached to the project (along with the source files), where it is possible to control things much more precisely per-project. more precisely, I had imagined essentially a hybrid of Makefiles and Bash. also imagined was the possibility of using JavaScript (or similar) as the build-control language, just using JS in a manner similar to Make+Bash, likely with some special-purpose API functionality (to make it more usable for Make-like purposes). a difficulty with JS though is that, normally, IDEs like things to be fairly declarative, and JS code its not declarative, unless the JS is split into multiple parts: info about the project proper is stored in a JSON-based format, and then any build logic is JS files attached to the project. so, the IDE would mostly just manage files and editors, and invoke the appropriate scripts as needed, and many IDE actions essentially just call functions, and so one causes something to happen by replacing the default action functions (such as in a script loaded by the project file). actually, conceptually I like the JS route more, even if it would likely be a little more verbose than a Bash-like syntax. IMO, the next best alternative is SciTE, so what I was imagining would be a more expanded version of SciTE. then there is also CMake, ... there is also SCons, which is conceptually related to the prior idea, but it based on Python. but, for the most part, I have mostly just ended up sticking with good old text editors and makefiles, as these have served me well, despite their drawbacks (the cost of switching to an alternative strategy likely being somewhat higher than that of doing nothing and staying with the present strategy). IOW, the if it aint broke, don't fix it strategy... or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: Electrical Actors?
On 6/6/2011 12:18 AM, Casey Ransberger wrote: Below:) On Jun 5, 2011, at 11:19 PM, C. Scott Ananiancsc...@laptop.org wrote: I explored this idea a bit once upon a time in the context of Java: http://cscott.net/Publications/design.pdf The bibliography cites most of the related work I know about. --scott Reading it now -- thanks for sharing this. I remember feeling so fascinated when I heard people talking about JavaOS on a chip; while I was aware of people jamming whole operating systems into ROM, the idea of an OS written mostly in a high level language by itself was completely new to me then (I was in highschool, I had only just secured Internet access for the first time) and it was just so compelling... You can do that?? was what I remember thinking, wait, how's that work... Oh I don't even care, forget about this manual memory management thing then! May I have a triple tall mocha with no whip? And do you do those in bulk orders? oh yeah... I remember something about this (I was either in middle or highschool at the time, I forget...). however, at the time, my motivation was mostly killed by me trying to use the language: oh... grr... using this language sucks... mostly I remember it being an issue about it being very painful to use, and also *absurdly* slow vs what I could do in C... so, I stuck with C, which was the main language I was using at the time. I think I remember originally hearing about Java when I was still in elementary school (long ago... back in the 90s...). It's a shame that it took me so many years to find Smalltalk. Sometimes I wish I could go back in time just to point myself at things. I may not have listened to future-me then, though, so I suppose the real lesson is to remember that I probably don't know anything of import even now, and that the best ideas I've got presently are likely to find hard judgement in my own eventual hindsight. most of my life has been me trying alternatives to C, and just being eventually like oh well, whatever... and sticking with C. the most serious I ever really got with developing in non-C language was with Scheme. eventually, I ended up rather burned with Scheme, as I eventually had to migrate back to plain C (the VM became unmaintainable), and ended up losing most of what code was written in or revolved around Scheme, and for a good while (a good number of years), I was determined to try to avoid recreating the situation which caused this (sadly... I am back to the situation once again, with a large highly-tooled codebase, with a lot of VM-related machinery in a fairly central role in the codebase, ...). I also have my own language (BGBScript) which is mostly in the JavaScript/ActionScript family, but it is mostly used for a few tasks: evaluating dynamically-entered expressions (entered at the console, similar to a REPL / Read Eval Print Loop); for triggered eval in a 3D engine (a map event triggers evaluating an expression string); high-level scripts (thus far, mostly only a few things involving 3D-rendered cutscenes and similar); ... however, I may consider using it for more serious activities in the future, if it is sufficiently proven (my current worries are mostly bugs/poor-performance/heap-gargbage/...). also a lesser worry of ending up with a lot of code in a language that for some reason I might end up having to drop or replace later. or such... ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] languages
On 6/6/2011 12:29 AM, Casey Ransberger wrote: I've heard of an IDE called VisualAge (I think?) that was written in Smalltalk but could parse and to a degree reason about other languages, but I've never seen it. Have you looked for that thing, or was it just not so great? not really looked at VisualAge... was intending here to look some at Code::Blocks, since I got thinking about IDEs some. personally, I have not been as much into Smalltalk, due mostly to my apparent inability to understand it when looking at it (look at syntax reference, look at code, feel utterly confused as to just what I am looking at...). (like, somehow, my brain can't really parse it or make much sense of it). I have taken some ideas off of both Smalltalk and Self, although in the form of a language I can more easily understand though... granted, there are other languages like this (like my apparent inability to really make sense of Haskell either). although, I can generally read/understand Forth and PostScript acceptably well, so I really don't know sometimes. although, recently when writing documentation for some parts of my language, and made an observation: str=Hello; s=str; while(*s) printf(%c, *s++); printf(\n); basically, along the lines of: holy crap... my language still retains a fair amount in common with C this was not originally intended (mostly, I was trying to implement ECMA-262 and add ActionScript and Java like features), just the combination of little things (implementing stuff, thinking oh well, this would be nifty...) happens to allow a few C-like constructions to be written. also: buf=new char[256]; str=Hello; t=buf; s=str; while(*t++=*s++); funny how this works sometimes... or such... On Jun 5, 2011, at 11:55 PM, BGB cr88...@gmail.com mailto:cr88...@gmail.com wrote: On 6/5/2011 11:03 PM, C. Scott Ananian wrote: On Sun, Jun 5, 2011 at 8:35 PM, BGB cr88...@gmail.com mailto:cr88...@gmail.com wrote: I would personally like to see an IDE which was: more-or-less language neutral, to what extent this was practical (more like traditional standalone editors); not tied to or hard-coded for particular tools or build configurations (nearly everything would be actions tied to high-level scripts, which would be customizable per-project, and ideally in a readily human-editable form); not being tied to a particular operating system; ... This is Eclipse. Granted, it's an IDE which is designed-by-committee and hard to love, but it answers all of your requirements. --scott I don't believe Eclipse is it, exactly... it handles multiple languages, yes, and can be used with multiple operating systems, and supports multiple compiler backends, ... however, AFAIK, pretty much all of the logic is written in Java-based plugins, which is not ideal (and so, essentially the logic is tied to Eclipse itself, and not to the individual projects). I was imagining something a little different here, such as the project control files being more like Makefiles or Bash-scripts, and so would be plain-text and attached to the project (along with the source files), where it is possible to control things much more precisely per-project. more precisely, I had imagined essentially a hybrid of Makefiles and Bash. also imagined was the possibility of using JavaScript (or similar) as the build-control language, just using JS in a manner similar to Make+Bash, likely with some special-purpose API functionality (to make it more usable for Make-like purposes). a difficulty with JS though is that, normally, IDEs like things to be fairly declarative, and JS code its not declarative, unless the JS is split into multiple parts: info about the project proper is stored in a JSON-based format, and then any build logic is JS files attached to the project. so, the IDE would mostly just manage files and editors, and invoke the appropriate scripts as needed, and many IDE actions essentially just call functions, and so one causes something to happen by replacing the default action functions (such as in a script loaded by the project file). actually, conceptually I like the JS route more, even if it would likely be a little more verbose than a Bash-like syntax. IMO, the next best alternative is SciTE, so what I was imagining would be a more expanded version of SciTE. then there is also CMake, ... there is also SCons, which is conceptually related to the prior idea, but it based on Python. but, for the most part, I have mostly just ended up sticking with good old text editors and makefiles, as these have served me well, despite their drawbacks (the cost of switching to an alternative strategy likely being somewhat higher than that of doing nothing and staying with the present strategy). IOW, the if it aint broke, don't fix it strategy... or such... ___ fonc mailing list
Re: Terseness, precedence, deprogramming (was Re: [fonc] languages)
Yep ... As Abrams pointed out, Beating should be pronounced Bee-Ating because it was a promotion scheme that reminded him of the beatification process in the path towards sainthood ... Cheers, Alan From: David Leibs david.le...@oracle.com To: Fundamentals of New Computing fonc@vpri.org Sent: Sun, June 5, 2011 9:59:33 PM Subject: Re: Terseness, precedence, deprogramming (was Re: [fonc] languages) Alan, Your memory for great dissertations is amazing. I don't think the Phil Abrams APL machine was ever actually built but It had some really good techniques for making APL efficient colorfully named beating and drag-along. -djl On Jun 5, 2011, at 7:50 PM, Alan Kay wrote: I think this one was derived from Phil Abrams' Stanford (and SLAC) PhD thesis on dynamic analysis and optimization of APL -- a very nice piece of work! (Maybe in the early 70s or late 60s?) Cheers, Alan From: David Pennell pennell.da...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Sun, June 5, 2011 7:33:40 PM Subject: Re: Terseness, precedence, deprogramming (was Re: [fonc] languages) HP had a version of APL in the early 80's that included structured conditional statements and where performance didn't depend on cramming your entire program into one line of code. Between the two, it was possible to create reasonably readable code. That version of APl also did some clever performance optimizations by manipulating array descriptors instead just using brute force. APL was the first language other than Fortran that I learned - very eye opening. -david On Sun, Jun 5, 2011 at 9:13 PM, Alan Kay alan.n...@yahoo.com wrote: Hi David I've always been very fond of APL also -- and a slightly better and more readable syntax could be devised these days now that things don't have to be squeezed onto an IBM Selectric golfball ... Cheers, Alan From: David Leibs david.le...@oracle.com To: Fundamentals of New Computing fonc@vpri.org Sent: Sun, June 5, 2011 7:06:55 PM Subject: Re: Terseness, precedence, deprogramming (was Re: [fonc] languages) I love APL! Learning APL is really all about learning the idioms and how to apply them. This takes quite a lot of training time. Doing this kind of training will change the way you think. Alan Perlis quote: A language that doesn't affect the way you think about programming, is not worth knowing. There is some old analysis out there that indicates that APL is naturally very parallel. Willhoft-1991 claimed that 94 of the 101 primitives operations in APL2 could be implemented in parallel and that 40-50% of APL code in real applications was naturally parallel. R. G. Willhoft, Parallel expression in the apl2 language, IBM Syst. J. 30 (1991), no. 4, 498–512. -David Leibs ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Re: Electrical Actors?
On Sun, Jun 5, 2011 at 8:13 PM, Casey Ransberger casey.obrie...@gmail.com wrote: On Jun 5, 2011, at 4:25 PM, Dale Schumacher dale.schumac...@gmail.com wrote: If someone has, I would sure like to hear about it! There was the Apiary machine, but I don't think that was ever physically built, only simulated. Googling... Tradeoffs in Designing a Parallel Architecture for the Apiary is a good place to start (http://dspace.mit.edu/handle/1721.1/41221?show=full). It seems that many of the related papers are not freely available. Maybe to deal with concurrency I should really start thinking of them as actor animators. I'm sure there's a way to pull this off. Even if it's by having a lot of FPGAs on the logic board so that I can compensate for reconfiguration latency by switching between them, but I don't think that idea fits any goal around a parsimonious architecture, which is one thing that I'm after. The synchronization problems I'd expect also seem awful, unless someone out there has thought a bunch about doing a low-level TeaTime (or what have you.) Actually, I think the parsimony principle is pretty well supported by low-level actors. I've built several actor run-time environments in software. The low-level machinery is quite small and simple. Its primary responsibilities are memory management and message dispatch. CREATE is memory allocation, BECOME is assignment and SEND is message construction (allocation) and queuing for dispatch. The rest of Humus was implemented on this simple core (http://www.dalnefre.com/wp/2010/08/evaluating-expressions-part-1-core-lambda-calculus/). The meta-circular description provides a semantic guide for direct machine-level implementation of the language components. Parsers and translators can also be built from low-level actors (http://www.dalnefre.com/wp/2011/02/parsing-expression-grammars-part-1/), allowing expression of actor scripts in textual form. Even the Humus simulator (http://www.dalnefre.com/humus/sim/humus.html) is built on a very small actor run-time core (http://www.dalnefre.com/humus/sim/actor.js) ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] languages
On Sunday 05 Jun 2011 12:16:33 AM Alan Kay wrote: People of my generation (50 years ago) were used to learning and using many syntaxes (e.g. one might learn as many as 20 or more machine code/assembler languages, plus 10 or more HLLs, both kinds with more variability in form and intent than today). Learning multiple languages didn't stop with your generation ;-). In the 80s, the fashion of the day was not only to learn many languages but also invent your own! One of the languages was called JOVIAL, an acronym for Jules Own Version of Algol! ;-) .. Subbu ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] languages
Hi Subbu Check out when Jules Schwartz actual did Jovial. And the acronym was actually Jules' Own Version of the International Algebraic Language Cheers, Alan From: K. K. Subramaniam kksubbu...@gmail.com To: fonc@vpri.org Cc: Alan Kay alan.n...@yahoo.com Sent: Mon, June 6, 2011 8:34:08 AM Subject: Re: [fonc] languages On Sunday 05 Jun 2011 12:16:33 AM Alan Kay wrote: People of my generation (50 years ago) were used to learning and using many syntaxes (e.g. one might learn as many as 20 or more machine code/assembler languages, plus 10 or more HLLs, both kinds with more variability in form and intent than today). Learning multiple languages didn't stop with your generation ;-). In the 80s, the fashion of the day was not only to learn many languages but also invent your own! One of the languages was called JOVIAL, an acronym for Jules Own Version of Algol! ;-) .. Subbu ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] languages
Alan, Thanks for the correction. IAL was one of the proposed names for the ALGOL, wasn't it? The reason why this name popped up from my grad days was because something as complicated as designing a new programming language was considered a fun thing to do. It wasn't as much fun for those who had to maintain programs written in them years down the line ;-). Gerald Weinberg's parody - Levine, the great Tailor - should serve as a lesson even today. Subbu On Monday 06 Jun 2011 9:37:02 PM Alan Kay wrote: Hi Subbu Check out when Jules Schwartz actual did Jovial. And the acronym was actually Jules' Own Version of the International Algebraic Language Cheers, Alan From: K. K. Subramaniam kksubbu...@gmail.com To: fonc@vpri.org Cc: Alan Kay alan.n...@yahoo.com Sent: Mon, June 6, 2011 8:34:08 AM Subject: Re: [fonc] languages On Sunday 05 Jun 2011 12:16:33 AM Alan Kay wrote: People of my generation (50 years ago) were used to learning and using many syntaxes (e.g. one might learn as many as 20 or more machine code/assembler languages, plus 10 or more HLLs, both kinds with more variability in form and intent than today). Learning multiple languages didn't stop with your generation ;-). In the 80s, the fashion of the day was not only to learn many languages but also invent your own! One of the languages was called JOVIAL, an acronym for Jules Own Version of Algol! ;-) .. Subbu ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
They are parsed just like variables. Rather than finding their declaration in the method itself they are known to the compiler. Hence pseudovariables. It also has the advantage that you don't have to pollute your literal frame since there are special bytecodes that handle them. Cheers, Toon On Jun 6, 2011 5:51 PM, Ondrej Bilka nel...@seznam.cz wrote: Hello As I started looking at squeak I am puzzled why true,false and nil are pseudovariables. Why they cannot be just constants like 0,1. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] languages
Inline On Jun 6, 2011, at 10:48 AM, Alan Kay alan.n...@yahoo.com wrote: It was ... and is mostly associated with what came to be called Algol 58, but not Algol 60. Another way to look at it is that almost all systems are difficult to maintain down the line -- partly because they were not designed with this in mind -- and this is true for most programming languages. However, I don't think this is necessary, but more an artifact of incomplete design. This, and design drift, wherein over time various forms of pseudo-arch get piled up and end up jutting out at weird angles:) Cheers, Alan ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] why are true,false,nil pseudovariables
My point is that you could just Object have methods true,false and nil Any reasonably optimalizing compiler would replace them with bytecode. On Mon, Jun 06, 2011 at 08:05:13PM +0200, Toon Verwaest wrote: They are parsed just like variables. Rather than finding their declaration in the method itself they are known to the compiler. Hence pseudovariables. It also has the advantage that you don't have to pollute your literal frame since there are special bytecodes that handle them. Cheers, Toon On Jun 6, 2011 5:51 PM, Ondrej Bilka nel...@seznam.cz wrote: Hello As I started looking at squeak I am puzzled why true,false and nil are pseudovariables. Why they cannot be just constants like 0,1. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Electrical Actors?
Casey, Has anyone taken the actor model down to the metal? I studied this in detail back in 1990 and had several references. These are physically hard for me to reach right now and probably are not easy to find on the web. Though not an actor model, you might find my RNA idea of objects and messages at the transistor level interesting: http://www.merlintec.com:8080/hardware/19 This text is mostly just a note to myself and probably doesn't make much sense to other people. An animation of the idea, however, would probably be easily understood even by children (and probably more easily by biologists than computer scientists, hence the forced acronym from Ring Network Architecture). I plan to work on this next year. -- Jecel ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Static typing and/vs. boot strap-able, small kernel, comprehensible, user modifiable systems
Ah thanks, I seem to have missed a large chunk of back-reading. I thought that Maude could do semantic typing, eg. in the parameterized views section of the maude manual ( http://maude.cs.uiuc.edu/maude2-manual/html/maude-manualch15.html). Could you expand on what you meant with the semantic typing stuff? As far as I understand OMeta, it's based on PEGs, and I understand it's non-determinitstic (and quite often non-terminating!), but I thought that PEGs required the target syntax to be unambiguous ie. in ambiguous cases there is a specified priority, so full context free grammars are out of reach (for say, natural language processing)? Maude's MSCP parser claims to be able to do this, and is apparently proven to interpret all possible analyses for each term (see http://maude.cs.uiuc.edu/maude1/manual/maude-manual-html/maude-manual_30.html ). I was interested in the real specifications that execute to produce prototypes (and can be debugged) aspect of programming. Being able to do this (and using meta-circularity to prove the whole software stack from the metal up), I'm guessing, would represent a big step forward. Thanks, Alexis On 5 June 2011 01:33, Alan Kay alan.n...@yahoo.com wrote: I like Maude (and most of the stuff done by or influenced by Joe Goguen). However, it is basically a term rewriting system that can overlap a bit with equational semantics. Nothing wrong with that, but much of it is essentially McCarthy's pure lisp semantics (nothing wrong with that either, but it does not really extend into the areas I was describing). And OMeta is non-deterministic (as are most of the TWSs we've done, including those that Ian Piumarta has used -- see his TCP example). Cheers, Alan -- *From:* Alexis Read alexis.r...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Sat, June 4, 2011 3:34:13 PM *Subject:* Re: [fonc] Static typing and/vs. boot strap-able, small kernel, comprehensible, user modifiable systems The extreme case of this -- where the variables are actually constrained to the specific values they are supposed to contain -- would be very useful if it could be made to generally work -- it amounts to declarative programming. Another extreme case would concern procedures/methods (we've called it semantic typing). For example, we want to find an operator that will do something specific -- like the sine function -- and we type our local name for this so that the only value it can have is a procedure that will compute sine. We could think of this as a kind of unit test for resources, or we could think of this as search criteria. Ted Kaehler implemented the Squeak method finder to do some of this. You give it examples of relations and it finds the methods. So 3 . 4 . 7 will yield both + and xor. 30 . 0.5 will find degreeSine, etc. There is actually a language that does the above - Maude. It supports strong dynamic typing (or as they call it sorts and subsorts) with subset inclusion eg. integers rational numbers irrational numbers, so in the case of type mismatch it can fall back to a different type (and error sorts are the last in the chain by default). Maude is also an equational language, so the number type example above can be done natively, and you can formally prove the type soundness (no SQL injection style bugs here!). Maude is a declarative language that has paramatized modules ie. you can constrain the parameters by type, the language will do the type matching for you as per the semantic typing above (you can specify matching strategies similar to ometa but more flexible due to the non-determinitstic parser). Types can be extended along with the rest of the language in a clean fashion - the Full Maude language including the object types is written in Core Maude. btw for those that haven't used Oberon (or it's most recent incarnation at the ETH, Bluebottle), as far as I'm aware the static typing is used at compile time, but not after that. As all the modules are hot-pluggable in the OS though, you can easily change types by recompiling, and I guess you could do a form of dynamic typing by auto-compiling modules at runtime. Static typing puts restrictions on what you ultimately can do, but for most tasks KISS (keep it simple stupid) applies and static typing certainly helps on the debugging side! Bootstrapping really isn't a problem - Bluebottle is working proof of this. On 4 June 2011 16:08, Alan Kay alan.n...@yahoo.com wrote: This issues were in conversations in the mid-60s when I was in grad school. One difference was that there was a computer (and more being thought of) -- the Burroughs B5000 -- that removed one of the motivations for static typing -- it implemented byte codes and 0 overhead dynamic type checking into the hardware which was organized as what would have been called the first capability architecture -- it was not crashable by a non-privileged
Re: [fonc] Electrical Actors?
On Sun, Jun 5, 2011 at 3:23 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Has anyone taken the actor model down to the metal? This would be difficult. We are constrained by fixed memory resources and connectivity relationships at the hardware level. The memory limits constrain scheduling in ways that may conflict with progress in the Actors model. The limited hardware connectivity means we cannot arbitrarily share references as first-class between actors. Another thought I had was using some nice symmetry that would let the processor do more than one thing at once. Of course if I shipped a microprocessor that had weird deadlock issues, I'd be inclined to call it a lemon. If you are not fixated on actors, I suggest you pursue other concurrency models: synchronous dataflow (Lustre, Estrel), Kahn process networks, clockless logic (e.g. Karl Font), event calculus, FRP, RDP, et cetera. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] languages
On Sat, Jun 4, 2011 at 10:44 AM, Julian Leviston jul...@leviston.netwrote: Is a language I program in necessarily limiting in its expressibility? Yes. All communication architectures are necessarily limiting in their expressiveness (in the sense defined by Matthias Felleisen). For example, can't easily introduce reactivity, concurrency, and constraint models to languages not already designed for them. Even with extensible syntax, you might be forced to re-design, re-implement. and re-integrate all the relevant libraries and services from scratch to take advantage of a new feature. Limitations aren't always bad things, though (e.g. when pursuing security, scalability, safety, resilience, modularity, extensibility, optimizations). We can benefit greatly from favoring 'principle of least power' in our language designs. Is there an optimum methodology of expressing algorithms (ie nomenclature)? No. From Kolmogorov complexity and pigeon-hole principles, we know that any given language must make tradeoffs in how efficiently it expresses a given behavior. The language HQ9+ shows us that we can (quite trivially) optimize expression of any given behavior by tweaking the language. Fortunately, there are a lot of 'useless' algorithms that we'll never need to express. Good language design is aimed at optimizing, abstracting, and refactoring expression of useful, common behaviors, even if at some expense to rare or less useful behaviors. Is there a good or bad way of expressing intent? There are effective and ineffective ways of expressing intent. We certainly want to minimize boiler-plate and noise. If our languages impose semantic properties (such as ordering of a collection) where we intend none, we have semantic noise. If our languages impose syntactic properties (such as semicolons) where they have no meaning to the developer, we have syntactic noise. If our languages fail to abstract or refactor some pattern, we get boiler-plate (and recognizable 'design patterns'). But we also don't want to sacrifice performance, security, modularity, et cetera. So sometimes we take a hit on how easily we can express intent. is there a way of patterning a language of programming such that it can extend itself infinitely, innately? Yes. But you must sacrifice various nice properties (e.g. performance, securability, modularity, composition) to achieve it. If you're willing to sacrifice ad-hoc extension of cross-cutting features (e.g. reactivity, concurrency, failure handling, auditing, resource management) you can still achieve most of what you want, and embed a few frameworks and EDSLs (extensible syntax or partial evaluation) to close the remaining expressiveness gap. If you have a decent concurrency and reactivity mode, you should even be able to abstract and compose IOC frameworks as though they were normal objects. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] languages
On 6/6/2011 6:05 PM, David Barbour wrote: On Sat, Jun 4, 2011 at 10:44 AM, Julian Leviston jul...@leviston.net mailto:jul...@leviston.net wrote: Is a language I program in necessarily limiting in its expressibility? Yes. All communication architectures are necessarily limiting in their expressiveness (in the sense defined by Matthias Felleisen). For example, can't easily introduce reactivity, concurrency, and constraint models to languages not already designed for them. Even with extensible syntax, you might be forced to re-design, re-implement. and re-integrate all the relevant libraries and services from scratch to take advantage of a new feature. Limitations aren't always bad things, though (e.g. when pursuing security, scalability, safety, resilience, modularity, extensibility, optimizations). We can benefit greatly from favoring 'principle of least power' in our language designs. interesting... the principle of least power is something I hadn't really thought about previously... Is there an optimum methodology of expressing algorithms (ie nomenclature)? No. From Kolmogorov complexity and pigeon-hole principles, we know that any given language must make tradeoffs in how efficiently it expresses a given behavior. The language HQ9+ shows us that we can (quite trivially) optimize expression of any given behavior by tweaking the language. Fortunately, there are a lot of 'useless' algorithms that we'll never need to express. Good language design is aimed at optimizing, abstracting, and refactoring expression of useful, common behaviors, even if at some expense to rare or less useful behaviors. yeah... I think many mainstream languages show this property, as they will often be specialized for some sets of tasks, but more far reaching features (ability to extend the syntax or core typesystem, ...) are generally absent. Is there a good or bad way of expressing intent? There are effective and ineffective ways of expressing intent. We certainly want to minimize boiler-plate and noise. If our languages impose semantic properties (such as ordering of a collection) where we intend none, we have semantic noise. If our languages impose syntactic properties (such as semicolons) where they have no meaning to the developer, we have syntactic noise. If our languages fail to abstract or refactor some pattern, we get boiler-plate (and recognizable 'design patterns'). But we also don't want to sacrifice performance, security, modularity, et cetera. So sometimes we take a hit on how easily we can express intent. yeah... usually with semicolons, it is either semicolons or significant line-breaks (or hueristics which try to guess whether a break was intended). semicolons then are the lesser of the evils. granted, yes, one wouldn't need either if the syntax were designed in a way where statements and expressions were naturally self-terminating, however, with common syntax design, this is often not the case, and so extra symbols are needed mostly as separators or to indicate the syntactic structure. is there a way of patterning a language of programming such that it can extend itself infinitely, innately? Yes. But you must sacrifice various nice properties (e.g. performance, securability, modularity, composition) to achieve it. If you're willing to sacrifice ad-hoc extension of cross-cutting features (e.g. reactivity, concurrency, failure handling, auditing, resource management) you can still achieve most of what you want, and embed a few frameworks and EDSLs (extensible syntax or partial evaluation) to close the remaining expressiveness gap. If you have a decent concurrency and reactivity mode, you should even be able to abstract and compose IOC frameworks as though they were normal objects. yep, and often a lot of this isn't terribly useful in practice. and, likewise, a lot of advanced functionality can be added more narrowly: API functionality; special purpose attributes or modifiers; ... personally, I keep around a few high power concepts, but these are far less than I could do. for example, I had gotten in arguments with someone before about my languages' lack of macro facilities or user-defined syntax extensions (or, at least, in-language syntax extensions). this was partly because both would open up additional and somewhat more awkward issues, for example, macros (in the Common Lisp sense) could risk exposing an uncomfortable number of implementation details. likewise goes for extensible syntax. some basic amount of extension is possible though mostly by registering callbacks, and at most levels of the tower it is possible to register new callbacks for new functionality (this is actually how a fair amount of the VM itself is implemented). most things are generally in a form more like how do I perform operation X given Y?, so lots of registering handlers for various operations, and
