Re: [fonc] languages

[BGB]

On 6/6/2011 6:05 PM, David Barbour wrote:



On Sat, Jun 4, 2011 at 10:44 AM, Julian Leviston > 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 registering p

Re: [fonc] languages

[David Barbour]

On Sat, Jun 4, 2011 at 10:44 AM, Julian Leviston 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.


>
> 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] Electrical Actors?

[David Barbour]

On Sun, Jun 5, 2011 at 3:23 PM, Casey Ransberger
wrote:
>
> 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] Static typing and/vs. boot strap-able, small kernel, comprehensible, user modifiable systems

[Alexis Read]

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  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 
>
> *To:* Fundamentals of New Computing 
> *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  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 b

Re: [fonc] Electrical Actors?

[BGB]

On 6/6/2011 11:53 AM, Jecel Assumpcao Jr. wrote:

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.


hmm, computer scientists can be scientists.

they just need a lab coat, some dark goggles, and to randomly interject 
"Science!" and "for Science!" into random/unrelated conversations.


and maybe somehow make a modern computer store data on a near by 
reel-to-real tape, or build robots or something.


programmers already use testing and similar though (like making tests 
and testing things).


ok, yes, this was sort of a lame joke...


or such...


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] languages

[BGB]

On 6/6/2011 10:29 AM, K. K. Subramaniam wrote:

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.


agreed...


but, yeah, designing a language is generally a fun/interesting thing to 
do, and so is working on the compiler/VM, fiddling with stuff, ... it 
gives much more of a sense of "doing stuff" than some other activities, 
and is not necessarily (entirely) busywork or mindless tedium either...


granted, yes, my designs tend to be fairly conservative (and not 
generally "minimalist"), as I don't personally believe in unnecessary 
novelty either.


but, one can simplify things when useful as well (say, when preexisting 
options either don't exist or are not very good, are overly cumbersome, 
or would be be a pain to implement, ...).



for example, I was recently (maybe 30 minutes ago) left considering the 
issue of what should be the syntax for type-specialized arrays.


in C, array types are known by context, so are not normally given in the 
syntax (although, IIRC, a cast can be used, say: "(char){ ... }");

Java does it like this: "new type[] { ... }";
my language declares normal arrays as "[ ... ]";
I couldn't determine if ActionScript had a similar feature.

for now, I opted with this: "[ ... ]suffix" and "[ ... ]:type".
where suffix is a generally 1-3 letter shorthand for certain common 
types, usually used for things like literals and similar, whereas the 
latter form would be the "general case".


so, for example, an array of bytes: "[16, 29, 32, 227, 113, 255]UB", as 
well as allowing this, "[3, 4, 5, 19, 340, 0]:byte"


this was because this seemed like the least effort, and this also looks 
less nasty than some other options. say, "[1, 2, 3, 4] as! byte[]", 
which is also slightly semantically misleading as well, since normally a 
cast like this would fail and raise an exception (note: "as" will return 
null if the cast fails, but "as!" will either cast or blow up; the 
traditional C-style cast syntax was removed as it created syntactic 
ambiguity, hence "as!").



or such...


___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] Electrical Actors?

[Jecel Assumpcao Jr.]

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] why are true,false,nil pseudovariables

[Ondrej Bilka]

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"  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] languages

[Casey Ransberger]

Inline

On Jun 6, 2011, at 10:48 AM, Alan Kay  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

[Toon Verwaest]

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"  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

[Alan Kay]

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.

Cheers,

Alan





From: K. K. Subramaniam 
To: Alan Kay 
Cc: fonc@vpri.org
Sent: Mon, June 6, 2011 10:29:49 AM
Subject: 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 
> To: fonc@vpri.org
> Cc: Alan Kay 
> 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

[K. K. Subramaniam]

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 
> To: fonc@vpri.org
> Cc: Alan Kay 
> 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 Kay]

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 
To: fonc@vpri.org
Cc: Alan Kay 
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

[fonc] why are true,false,nil pseudovariables

[Ondrej Bilka]

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

Re: [fonc] languages

[K. K. Subramaniam]

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

[fonc] Re: Electrical Actors?

[Dale Schumacher]

On Sun, Jun 5, 2011 at 8:13 PM, Casey Ransberger
 wrote:
> On Jun 5, 2011, at 4:25 PM, Dale Schumacher  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: Terseness, precedence, deprogramming (was Re: [fonc] languages)

[Alan Kay]

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 
To: Fundamentals of New Computing 
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 
>To: Fundamentals of New Computing 
>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  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 
>>To: Fundamentals of New Computing 
>>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

Re: [fonc] languages

[BGB]

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 > wrote:



On 6/5/2011 11:03 PM, C. Scott Ananian wrote:
On Sun, Jun 5, 2011 at 8:35 PM, BGB > 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 

Re: [fonc] Re: Electrical Actors?

[BGB]

On 6/6/2011 12:18 AM, Casey Ransberger wrote:

Below:)

On Jun 5, 2011, at 11:19 PM, "C. Scott Ananian"  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

[Casey Ransberger]

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  wrote:

> On 6/5/2011 11:03 PM, C. Scott Ananian wrote:
>> 
>> On Sun, Jun 5, 2011 at 8:35 PM, BGB  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?

[Casey Ransberger]

Below:)

On Jun 5, 2011, at 11:19 PM, "C. Scott Ananian"  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

[BGB]

On 6/5/2011 11:03 PM, C. Scott Ananian wrote:
On Sun, Jun 5, 2011 at 8:35 PM, BGB > 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