Re: [fonc] Kernel Maru
This one seems to be available as a technical report as well: http://infolab.stanford.edu/TR/CS-TR-65-20.html Monty On Wed, Apr 11, 2012 at 4:44 AM, Alan Kay alan.n...@yahoo.com wrote: One more that is fun (and one I learned a lot from when I was in grad school in 1966) is Niklaus Wirth's Euler paper, published in two parts in CACM Jan and Feb 1966. This is a generalization of Algol via some ideas of van Wijngaarten and winds up with a very Lispish kind of language by virtue of consolidating and merging specific features of Algol into a more general much smaller kernel. The fun of this paper is that Klaus presents a complete implementation that includes a simple byte-code interpreter. This paper missed getting read enough historically (I think) because one large part of it is a precedence parsing scheme invented by Wirth to allow a mechanical transition between a BNF-like grammar and a parser. This part was not very effective and it was very complicated. So just ignore this. You can use a Meta II type parser (or some modern PEG parser like OMeta) to easily parse Euler directly into byte-codes. Everything else is really clear, including the use of the Dijkstra display technique for quick access to the static nesting of contexts used by Algol (and later by Scheme). Cheers, Alan From: Monty Zukowski mo...@codetransform.com To: Fundamentals of New Computing fonc@vpri.org Sent: Tuesday, April 10, 2012 9:20 PM Subject: Re: [fonc] Kernel Maru Thank you everyone for the great references. I've got some homework to do now... Monty On Tue, Apr 10, 2012 at 2:54 PM, Ian Piumarta piuma...@speakeasy.net wrote: Extending Alan's comments... A small, well explained, and easily understandable example of an iterative implementation of a recursive language (Scheme) can be found in R. Kent Dybvig's Ph.D. thesis. http://www.cs.unm.edu/~williams/cs491/three-imp.pdf Regards, Ian ___ 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 mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Kernel Maru
Yes, it looks like this is it. $37 for a PDF. Thanks! CONTROL STRUCTURES FOR PROGRAMMING LANGUAGES by FISHER, DAVID ALLEN, Ph.D., Carnegie Mellon University, 1970, 215 pages; AAT 7021590 On Tue, Apr 10, 2012 at 11:54 AM, Duncan Mak duncan...@gmail.com wrote: On Tue, Apr 10, 2012 at 2:34 PM, Monty Zukowski mo...@codetransform.com wrote: If anyone finds an electronic copy of Fisher's thesis I'd love to know about it. My searches have been fruitless. The title is not the same, but maybe these are variants of the same paper? http://dl.acm.org/author_page.cfm?id=81100550987coll=DLdl=ACMtrk=0cfid=76786786cftoken=53955875 Also, I no longer have access to ACM digital library, so I can't post the PDFs. -- Duncan. ___ 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] Kernel Maru
Thank you everyone for the great references. I've got some homework to do now... Monty On Tue, Apr 10, 2012 at 2:54 PM, Ian Piumarta piuma...@speakeasy.net wrote: Extending Alan's comments... A small, well explained, and easily understandable example of an iterative implementation of a recursive language (Scheme) can be found in R. Kent Dybvig's Ph.D. thesis. http://www.cs.unm.edu/~williams/cs491/three-imp.pdf Regards, Ian ___ 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] The Language Barrier
Have you seen Causeway? Sounds like it might be a start toward what you desire. http://www.erights.org/elang/tools/causeway/ Causeway is an open source postmortem distributed debugger for examining the behavior of distributed programs built as communicating event loops. Its message-oriented approach follows the flow of messages across process and machine boundaries. http://www.hpl.hp.com/techreports/2009/HPL-2009-78.html An increasing number of developers face the difficult task of debugging distributed asynchronous programs. This trend has outpaced the development of adequate debugging tools and currently, the best option for many is an ad hoc patchwork of sequential tools and printf debugging. This paper presents Causeway, a postmortem distributed debugger that demonstrates a novel approach to understanding the behavior of a distributed program. Our message-oriented approach borrows an effective strategy from sequential debugging: To find the source of unintended side- effects, start with the chain of expressed intentions. We show how Causeway's integrated views - describing both distributed and sequential computation - help users navigate causal pathways as they pursue suspicions. We highlight Causeway's innovative features which include adaptive, customizable event abstraction mechanisms and graphical views that follow message flow across process and machine boundaries. Monty On Fri, Aug 19, 2011 at 3:26 PM, Casey Ransberger casey.obrie...@gmail.com wrote: At work there are generally a small pile of languages in play: a backend language (Perl and Java seem common here,) sometimes a separate language for the web front end, this has often been Ruby of late, a relational language (thus far always a SQL variant,) and the now ubiquitous Javascript. I test big web apps, usually. When I'm doing automation, I'm often frustrated by a language barrier. Sometimes I can get a lot of mileage out of a meta-object protocol in languages which have one. But as the application under test is regularly written in multiple languages, the places where different subcomponents connect are problematic, I lose this leverage here, because these languages don't share a MOP. In the future, I want to be able to have this cake and eat it too. I'm not sure what that looks like or even what to call it. Maybe it's a domain specific language for test automation, or perhaps more interestingly, a meta-meta-object protocol (TM!) I note that when my backend is written in Java, it still makes some sense to choose (of the company approved languages) e.g. Ruby to do the automation. More and more I just wish they'd let me use Lisp. This is partly because I'm typically outnumbered by line developers by a wide margin and want all of the leverage I can get. I wonder what people here would think about these ideas. Alex Warth mentioned an omnidebugger and I almost wonder if whatever approach works for that might work for this. Maybe a common intermediate representation is all I need to do it. -- Casey Ransberger ___ 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] Extending object oriented programming in Smalltalk
The Little Lisper is one of my favorite computer books. I think it teaches the idea of Lisp, though without expounding on it. Monty On Thu, Aug 18, 2011 at 1:33 AM, BGB cr88...@gmail.com wrote: On 8/17/2011 6:41 PM, Alan Kay wrote: Take a look at Landin's papers and especially ISWIM (The next 700 programming languages) You don't so much want to learn Lisp as to learn the idea of Lisp now, I am wondering some what is exactly the idea of Lisp? putting the phrase into Google doesn't seem to turn up many obvious candidates. a guess: only a few syntax elements and types can represent a large variety of stuff (like, the world can be built up from a reasonably simple core). tried to make other guesses, but none really seem to stick. maybe also code is data and a few other things. (sorry, I tend to be a bit literal-minded and am not always so good at figuring out things like this). actually, it is sort of like the task of trying to write out a spec for a high-level overview of my object system and core typesystem and semantics. one has a sense of what it is, but trying to effectively explain it is difficult. basic idea: class-instance + dynamic extension + delegation + scopes-are-objects + ... sorry, I don't mean to make my stuff seem overly important, even if I am prone to write about it a lot. Cheers, Alan From: karl ramberg karlramb...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Wednesday, August 17, 2011 12:00 PM Subject: Re: [fonc] Extending object oriented programming in Smalltalk Hi, Just reading a Lisp book my self. Lisp seems to be very pure at the bottom level. The nesting in parentheses are hard to read and comprehend / debug. Things get not so pretty when all sorts of DSL are made to make it more powerful. The REPL give it a kind of wing clipped aura; there is more to computing than text io Karl On Wed, Aug 17, 2011 at 8:00 PM, DeNigris Sean s...@clipperadams.com wrote: Alan, While we're on the subject, you finally got to me and I started learning LISP, but I'm finding an entire world, rather than a cohesive language or philosophy (Scheme - which itself has many variants, Common LISP, etc). What would you recommend to get it in the way that changes your thinking? What should I be reading, downloading, coding, etc. Thanks. Sean DeNigris You wouldn't say that Lisp 1.5 Programmer's Manual is outdated would you? :-) ___ 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 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] misc: code security model
A huge amount of work has been done in this area in the capability
security world. See for instance the reference to Mark Miller's
thesis in the footnotes of
http://en.wikipedia.org/wiki/Object-capability_model
A short summary of capability security is that checking permissions is
error prone. Instead, only give out objects you want other pieces to
use. In essence there is no global namespace, instead your
supervisor environment only hands out the capabilities that you've
decided the program that will be run needs.
The canonical example is
cp a.txt b.txt
vs.
cat a.txt b.txt
cp needs access to the global namespace to find a.txt and b.txt and
permissions are checked, etc. That is giving cp the authority to
actually modify files other than a.txt and b.txt.
The cat example is simple to reason about. The only objects cat
needs are the input and output file descriptors, and the shell in this
case is the supervisor which hands these capabilities to cat. It
doesn't need any access to the filesystem and so should not be granted
the ability to get directory listings or open other files that the
user running the program might have access to.
At a language level one of my favorite papers is
http://bracha.org/newspeak-modules.pdf because it addresses the issue
of the top level namespace of a language without making it globally
accessible.
Monty
On Wed, Aug 10, 2011 at 7:35 PM, BGB cr88...@gmail.com wrote:
well, ok, this is currently mostly about my own language, but I figured it
might be relevant/interesting.
the basic idea is this:
not all code may be from trusted sources.
consider, say, code comes from the internet.
what is a good way of enforcing security in such a case?
first obvious thing seems to be to disallow any features which could
directly circumvent security.
say, the code is marked untrusted, and the first things likely to happen
would be to disable access to things like raw pointers and to the C FFI.
the second thing seems to be the option of moving the code to a local
toplevel where its ability to see certain things is severely limited.
both of these pose problems:
simply disabling compiler features may not be sufficient, since there may be
ways of using the language which may be insecure and which go beyond
simply enabling/disabling certain features in the compiler.
anything still visible may be tampered with, for example, suppose a global
package is made visible in the new toplevel, and the untrusted code decides
to define functions in a system package, essentially overwriting the
existing functions. this is useful, say, for writing program mods, but may
be a bad things from a security perspective.
a partial option is to give untrusted code its own shadowed packages, but
this poses other problems.
similarly, an exposed API function may indirectly give untrusted code
unexpected levels of power if it, by default, has unhindered access to the
system, placing additional burden on library code not to perform operations
which may be exploitable.
consider something trivial like:
function getTopVar(name) { return top[name]; }
which, if exposed under a visibility-based security scheme, and the function
was part of a library package (with full system access), now suddenly the
whole security model is dead. essentially it would amount to trying to
create water tight code to avoid potential security leaks.
another security worry is created by, among other things, the semantics of
object delegation (at least in my language), where assigning through a
delegated object may in-turn move up and assign the variable in a
delegated-to object (at the VM level there are multiple assignment operators
to address these different cases, namely which object will have a variable
set in...).
this in-turn compromises the ability to simply use delegation to give each
module its own local toplevel (effectively, the toplevel, and any referenced
scopes, would need to be cloned, so as to avoid them being modified), ...
so, I am left idly wondering:
could a variation of, say, the Unix security model, be applied at the VM
level?
in this case, any running code would have, say, a UID (UserID, more refers
to the origin of the code than to the actual user) and GID (GroupID). VM
objects, variables, and methods, would themselves (often implicitly) have
access rights assigned to them (for example: Read/Write/Execute/Special).
possible advantages:
could be reasonably secure without going through contortions;
lessens the problem of unintended levels of power;
reasonably transparent at the language level (for the most part);
...
disadvantages:
have to implement VM level security checking in many places;
there are many cases where static validation will not work, and where
runtime checks would be needed (possible performance issue);
may add additional memory costs (now, several types of memory objects will
have to remember their owner and access rights,
Re: [fonc] Reverse OMeta and Emulation
GNU C was explicitly designed to make its intermediate representation hard to work with. LLVM is a more practical choice. Monty On Mon, Jun 21, 2010 at 6:02 PM, Gerry J geral...@tpg.com.au wrote: You may find the concept of semantic slicing relevant: http://www.cse.dmu.ac.uk/~mward/martin/papers/csmr2005-t.pdf There is software at: http://www.cse.dmu.ac.uk/~mward/fermat.html One possible path to explore is to take GNU C etc intermediate representation of source as the assembly language of a VM and reverse from that to a more portable VM, as in Squeak or Java. Perhaps Ometa could be combined in some way with FermaT to recognise patterns and port legacy code to a fonc VM ? Regards, Gerry Jensen 02 9713 6004 ___ 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] Specification of Word Wrap and a Text Editor
Lout ( http://sourceforge.net/apps/mediawiki/lout/index.php?title=Main_Page ) has a very interesting design for text layout. It is in fact a DSL for page layout, and a quirky but powerful one at that. Even so he has a good discussion of handling regions of text and larger structures such as pages and documents. The Design and Implementation of the Lout Document Formatting Language http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.9234 The author Jeffrey Kingston is slowly working on a successor called Nonpareil, for which he is designing a suitable functional language on top of which to build the new page layout language. You might find some inspiring ideas in his work. Monty ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] crypto metalanguage
I wanted to bring to your attention Ben Laurie's Stupid: A Metalanguage For Cryptography. Despite the name it actually is helpful for abstracting the design of cryptographic algorithms. http://www.links.org/?p=864 Monty ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
