Re: [fonc] Really nice presentation of the VPRI project
At Thu, 14 Nov 2013 23:13:29 -0700, David Girle wrote: Figure 1 of TR-2013-002, KScript and KSWorld ... would appear to indicate the headless piece of Frank might be 2-3,000 LOC ? Would that be a possible first step to publish, before the full 10,000 LOC ? That may be an option, right. -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Really nice presentation of the VPRI project
At Fri, 15 Nov 2013 17:42:38 +1100, Julian Leviston wrote: I'm curious, does Frank and its precursors (sub-cursors?) include sound, or only visual languages? Some sound processing was experimented in Nile, and a small application to control it was written in KSWorld, but the Frank document editor never provided a real sound features. -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Really nice presentation of the VPRI project
I still want to release Frank for example... We revised the syntax of KScript during the its life time and still many parts of it is written in the old syntax. Yes, it is about 10,000 lines of code, but it is still some work to convert them all. A movie of demo would be good, yes. Thank you for the interest! On Mon, Nov 11, 2013 at 11:11 AM, Brian Rice briantr...@gmail.com wrote: Well, I certainly appreciate the effort and can fill in some details from how long we've been tracking the project externally. That said, I look forward to some more concrete and hopefully interactive details. Right now, it's difficult for me to communicate this to others except in person with a lot of hand-waving. On Mon, Nov 11, 2013 at 10:43 AM, Yoshiki Ohshima yoshiki.ohsh...@acm.org wrote: At Sat, 9 Nov 2013 10:37:02 +0100, Loup Vaillant-David wrote: I don't understand the first link... Am I supposed to find a video recording there? There is no video recording but only the slides in the PDF file. I'm afrait that some of the stuff in it may not make sense unless accompanied by commentary. -- Yoshiki On Fri, Nov 08, 2013 at 01:12:24PM +0100, karl ramberg wrote: http://d.hatena.ne.jp/squeaker/20131103#p1 http://tinlizzie.org/~ohshima/AGERE2013/AGERESlides.pdf (33 Mb) Cheers, Karl ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- -Brian T. Rice ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Really nice presentation of the VPRI project
Thank you, Karl! An interesting thing happened at the conference (I'ts about David Ungar asking a question to type theorists). I wrote about it (in Japanese): http://d.hatena.ne.jp/squeaker/20131101#p1 On Fri, Nov 8, 2013 at 4:12 AM, karl ramberg karlramb...@gmail.com wrote: http://d.hatena.ne.jp/squeaker/20131103#p1 http://tinlizzie.org/~ohshima/AGERE2013/AGERESlides.pdf (33 Mb) Cheers, Karl ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Really nice presentation of the VPRI project
On Fri, Nov 8, 2013 at 5:33 PM, Yoshiki Ohshima yoshiki.ohsh...@acm.org wrote: Thank you, Karl! An interesting thing happened at the conference (I'ts about David Ungar asking a question to type theorists). I wrote about it (in Japanese): http://d.hatena.ne.jp/squeaker/20131101#p1 I gather that letting Google to translate it is a bad idea; so I attempted to do it by myself. http://d.hatena.ne.jp/squeaker/20131109#p1 -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Afterword: What is a Dynabook?
http://www.vpri.org/pdf/hc_what_Is_a_dynabook.pdf -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Afterword: What is a Dynabook?
At Thu, 3 Oct 2013 16:15:12 -0700, James McCartney wrote: In the early 60s JCR Licklider, a psychologist at the Advanced Research Projects Agency put forth a great vision: “It is the destiny of computers to become interactive intellectual amplifiers for all people pervasively networked worldwide”. Because ARPA probably would have rejected funding for a worldwide system for the interchange of kitty pictures and porn. And one-line smart-ass comments like this one. (Sorry, could not resist.) -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] New Bret Victor demos
On Wed, May 29, 2013 at 9:59 AM, karl ramberg karlramb...@gmail.com wrote: Bret Victor have made available some nice demonstrations of uses of a _very_ Frank like system. In one he is visualizing Gezira and Nile by Dan Amelang http://worrydream.com/#!/MediaForThinkingTheUnthinkable http://worrydream.com/#!/DrawingDynamicVisualizationsTalk http://worrydream.com/#!/MediaForThinkingTheUnthinkable Thank you, Karl! The first one and the third one seem to point to the same page. Did you meant to put a link to another page? -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Report Card
Making our code public would have been ideal. The problem was that we don't know how the system should look like, and things have gone so many iterations. In a way, I regret that we couldn't do a good job making code public, but in other ways, I'm glad we didn't as we did not have to feel bad about letting people see what we already abandoned. (It did happen with IdSt, for example.) Incidentally, we have a new research note up on our web site. And the annuall and final report is very close to be released. (Speaking of new hardware, enchantMOON has gotten to the pre-order stage. http://enchantmoon.com/) On Tue, Apr 23, 2013 at 10:05 PM, David Girle davidgi...@gmail.com wrote: I cannot address report card. I have greatly enjoyed the papers and respect the aspiration to deliver a system in ~20kLOC by leveraging algorithms and Moore's law. A system, with size and elegance, that folks could get their head around. Your point on discussion of what has already been published is well made ... for instance I have not seen a lot of posts on people's experiences with say Maru. In my own case, I had a lot of learning (as I have no Lisp experience) and little time (and will not, until my business sells). Also, I was hesitant to engage on a code base that was likely well behind what was privately available, particularly for things like sockets/files. Ian was kind enough to respond to a couple of requests. My hope is that VPRI will publish their report and ideally some artifact code. Having written a small system with an mbed target and dart server, dart/SVG browser client, it is clear how unpleasant working with the mbed device in C/C++ is compared to a modern language and accompanying libraries. The new beaglebone http://www.youtube.com/watch?feature=player_embeddedv=ciX08ysl6LE allows programming in Javascript, but it would be nice to move beyond that. With thanks for what has been achieved and published, david On Mon, Apr 22, 2013 at 11:04 AM, Yoshiki Ohshima yoshiki.ohsh...@acm.org wrote: On Fri, Apr 19, 2013 at 1:51 PM, Casey Ransberger casey.obrie...@gmail.com wrote: I wanted to send this message out after the final status report, but since that's indefinitely delayed (keep going!) I'm just going to do it now. Easy question: has keeping this dialogue open been useful to the folks at VPRI, or has it been more of a burden than anything else? Burden is not the word I'd use, but as everybody would agree, the S/N ratio has not been too high. I personal think that we, the folks at VPRI, need to take a bit of blame for that. We could have written more regularly what we are doing to steer the conversation. (But maybe using words like foundation and new in the title of the mailing list did not help us to have reasonable conversations^^;) At the same time, we did publish research notes and memos now and then, but very, very, little about them were brought up (Casey, you did mention some of it, I appreciate it!); some questions and discussions indicated that some people commented on our work without reading the original proposal or annual reports. That was slightly unfortunate. I can definitely say that it's been very good for me, in that I learned a hell of a lot reading all of the lovely papers posters cited. It's also been a lot of fun meeting people who were interested in a lot of the same things that I was. I learned a lot, too. VPRI has done something pretty awesome and weird here, in that the dialogue was wide open the whole time. As I gather, it was in the spirit of ARPA. We've had our share of trolls, long-winded posters (raises hand) and just general chaos. I really enjoyed the guy who called us all a bunch of Alan Kay fanboys the other day by the way. That was just priceless. Like we can't think for ourselves! (Alan if I can get an autograph after this I think I'll be set.) So seriously, has this been worthwhile? I'm not just asking VPRI folks, though I'm DEFINITELY asking VPRI folks, I'm also asking everyone else on the list. I learned a lot, huge win for me, and we talked in circles a bunch, some of that was fun. I can also think of a few parts where I felt pretty strongly that it *was* worthwhile. To throw out an example, remember when Dale Schumacher asked pretty poignantly whether or not the original idea behind objects/messages was similar to the actor model? That was like a blockbuster for nerds it was so awesome. That totally rocked. That's me. Okay now talk amongst yourselves go! ? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo
Re: [fonc] enchantMOON
Yup. Certainly your opinion goes along the conventional wisdom. (It is not Scratch but their tile-based scripting system inspired by Scratch.) I have my own share of doubts and wonder how much improvement they manage to put since January, when we saw a prototype working. But it is commendable that they make hardware and customized OS and drivers just to support a single idea they want, which is to have a good response for hand drawing and a customizable platform by the end-user. An they did manage to start selling it. I'd say let us see. On Thu, Apr 25, 2013 at 4:47 PM, Josh Grams j...@qualdan.com wrote: On 2013-04-25 11:30AM, Yoshiki Ohshima wrote: (Speaking of new hardware, enchantMOON has gotten to the pre-order stage. http://enchantmoon.com/) Is there anything interesting about that other than that it appears to have Scratch inside? There doesn't seem to be anything on their website other than a video, and from the video, the user interface looks to be horrifyingly bad. - It starts up with what looks like a moon waxing, but when it gets to be a full moon, you find out that it's *not* actually done loading, it's just displaying a moon spinning. If you have a progress bar, it should either represent a fraction of progress or it should just give an indicator that the computer is busy and hasn't crashed and should very clearly *not* look like a fraction of anything. - It seems to have a lot of interface glitz which just slows things down and serves no useful purpose whatever. If I click a button, I don't want to watch a little explosion of growing dots, I just want it to go to the next screen. It might be cute the first eight times, but after that it's just annoying. For serious use, half a second to wait for some stupid animation to play before it does what I tell it to do is at least two or three times too long. - The handwriting recognition is so incredibly slow that at one point the user starts to correct his writing thinking that the system hasn't recognized it at all...if I was going to use it, I'd want to see it be about an order of magnitude faster. Isn't the rule of thumb that ideally things should take less than a tenth of a second, and if they take more than twice that they should show a progress or busy indicator? - Buttons which orbit? Really? That's just incredibly stupid. I don't want to have to read the buttons to figure out which one is which. On a touch-screen device should definitely be able to just *know* where they are and be able to stab the right one without looking. - And this is a trivial thing, but why are these people so totally incompetent that they posted a demo video with two minutes of blank frames at the end? If they're so lazy that they can't be bothered to double-check a four-minute video before they post it, I definitely don't trust them to write software which doesn't suck. --Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Report Card
On Fri, Apr 19, 2013 at 1:51 PM, Casey Ransberger casey.obrie...@gmail.com wrote: I wanted to send this message out after the final status report, but since that's indefinitely delayed (keep going!) I'm just going to do it now. Easy question: has keeping this dialogue open been useful to the folks at VPRI, or has it been more of a burden than anything else? Burden is not the word I'd use, but as everybody would agree, the S/N ratio has not been too high. I personal think that we, the folks at VPRI, need to take a bit of blame for that. We could have written more regularly what we are doing to steer the conversation. (But maybe using words like foundation and new in the title of the mailing list did not help us to have reasonable conversations^^;) At the same time, we did publish research notes and memos now and then, but very, very, little about them were brought up (Casey, you did mention some of it, I appreciate it!); some questions and discussions indicated that some people commented on our work without reading the original proposal or annual reports. That was slightly unfortunate. I can definitely say that it's been very good for me, in that I learned a hell of a lot reading all of the lovely papers posters cited. It's also been a lot of fun meeting people who were interested in a lot of the same things that I was. I learned a lot, too. VPRI has done something pretty awesome and weird here, in that the dialogue was wide open the whole time. As I gather, it was in the spirit of ARPA. We've had our share of trolls, long-winded posters (raises hand) and just general chaos. I really enjoyed the guy who called us all a bunch of Alan Kay fanboys the other day by the way. That was just priceless. Like we can't think for ourselves! (Alan if I can get an autograph after this I think I'll be set.) So seriously, has this been worthwhile? I'm not just asking VPRI folks, though I'm DEFINITELY asking VPRI folks, I'm also asking everyone else on the list. I learned a lot, huge win for me, and we talked in circles a bunch, some of that was fun. I can also think of a few parts where I felt pretty strongly that it *was* worthwhile. To throw out an example, remember when Dale Schumacher asked pretty poignantly whether or not the original idea behind objects/messages was similar to the actor model? That was like a blockbuster for nerds it was so awesome. That totally rocked. That's me. Okay now talk amongst yourselves go! ? ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Behavior reuse through copy and paste between applications.
On Fri, Mar 29, 2013 at 9:19 PM, John Carlson yottz...@gmail.com wrote: I'm not sure if this is on subject or not. I recently considered not only copying data between applications, but also copying behavior. I know the typical response would be to tell the user to go find the behavior in the source code or library. What if some simple keystrokes could copy and paste behavior? Which systems have done this? Thanks in advance. This may be a tangential answer but Scratch lets you drop a stack of block from one sprite to another. -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Behavior reuse through copy and paste between applications.
On Fri, Mar 29, 2013 at 10:10 PM, John Carlson yottz...@gmail.com wrote: I'm thinking more about copying behavior between different address spaces. Hehe, I thought so, too. Scratch 2.0 has the Backback so you can (sort of) do it remotely. The question is, when you want to copy and paste things from a different language, what the fundamental execution model is. You'd bring the interpreter and/or the parser of the language with copied code. I heard that the CompiledMethod object in an earlier Smalltalk implementation had interpreter field, or at least they talked about it. As long as the receiving side recognizes it in some way, it would be something conceivable... -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Sources for Functional Reactive Programming
On Thu, Feb 21, 2013 at 1:15 PM, Casey Ransberger casey.obrie...@gmail.com wrote: Didn't know this term, and worrying that I was completely misunderstanding the use of the term behavior, I googled and found these: http://conal.net/papers/icfp97/ http://haskell.cs.yale.edu/wp-content/uploads/2011/02/genuinely-functional-guis.pdf There's a Wikipedia article, but it's very sparse. Anything else I should read? Yes, I think it is unfortunate that they picked the term behavior to mean continuous time-varying entity. A generic term behavior does not have the connotation of continuous, as far as I can tell. To me, the Flapjax paper and their tutorial are more intuitive (whatever that means) http://www.flapjax-lang.org/publications/ -- -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Debugging PEGs and Packrats
At Wed, 14 Dec 2011 09:35:06 +0100,
Lukas Renggli wrote:
I've experimented in what little time I can devote with OMeta, PetitParser,
and Treetop. The debugging experience has been roughly consistent across
all three.
Casey, did you try the PetitParser IDE? If so, what did you miss?
If not, please check it out
(http://jenkins.lukas-renggli.ch/job/PetitParser/lastSuccessfulBuild/artifact/PetitParser-OneClick.zip).
It comes with dedicated tools for grammars (editor, visualizations,
profiler, debugger, ...). An earlier version of the tool is described
in Section 3.5 of this paper
(http://scg.unibe.ch/archive/papers/Reng10cDynamicGrammars.pdf). We
are currently working on an improved IDE with grammar refactorings.
Wow. Pretty cool.
I'm playing with it a bit, and trying to figure out how I'd detect
an error in my grammar. I introduced a bug in PPJsonGrammer by
changing string to read (omit the last $ asParser):
string
^ $ asParser , char star
and chose Dynamic and put {a: 1, b: 2} and said parse. I see
the tree and the parse goes as far as position 3. But of course, it
is not easy to tell that #string has the problem from this. (I'd
think that this is the nature of grammar writing, where the parser
basically does not know what makes sense, especially if there are
other choices.
OMeta2/Squeak has a feature to pop up a Squeak debugger at the
position where the parse went as far as it could, and then you can
step execute it. But of course, it goes into the underlying
implementation and generated code, so it is quite tedious. What we
would like to see in that debugger is the original code and step
execution that makes sense.
Of course, Squeak debugger lets you restart a context, but this
does not help much as the parser is stateful. We contemplated Worlds
would help to really rewind a rule and try again...
-- Yoshiki
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
Re: [fonc] VPRI Presentations (e.g. C5 2012)
At Mon, 28 Nov 2011 11:16:50 -0500, DeNigris Sean wrote: Will you notify the list when VPRI presentations are scheduled? For example, is anyone planning on presenting at C5 2012? It would effect my conference selection through the year because STEPS seems like the most important work in software right now. As Kim said, none of VPRI people ended up submitting a paper. But many of us will be there and happy to show whatever we've got (by that time, hehe). -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Re: Improving efficiency of Worlds, in Software and Hardware
Thank you for the links, Scott! At Tue, 14 Jun 2011 21:42:17 -0400, C. Scott Ananian wrote: (As a minor technical note: it appears that the implementation of flattenHistory in figure 4 occurs in the wrong order. Worlds should be committed from the root to the leaves, shouldn't they?) In that example, the organization is a straight links so that may have been confusing but the general idea of worlds is somewhat like the nested transactions; it is a tree of worlds, and a mid-level worlds represents all the state changes occured all transient children worlds. And you sort of honor the top-level world; it could be considered the persistent object that represents non-revertable memory. During the process of commiting worlds from the leaf to root (which is the only direction allowed as not having the double-linked pointers helps simplifying the design and also helps the garbage collection, etc. btw) at any moment you can take the leaf world at that moment and view the state of the application from within the world, and you basically won't notice if the commiting process is ongoing. And when the commiting reaches the root, the state in the root is fully updated yet the user's view still does not change. So, at least it is not wrong, I think. In one of the past implementation of worlds, Alex spent so much time to make the automatic coalesing of worlds work; Upon finalizing a world that is no longer referenced is reclaimed and all content in it gets pushed down to its children, and then these children get re-linked to the grand parent. This was effectively commiting data from parent to child. Yes, it indeed has some attractive nature in some situations. For example, let us say we have an application (model) that has some history but let multiple users observe the application. Let us say the chain of state is: TopW - W1 - W2 - W3 (Let's say - means these are doubly-linked.) The good thing about this is that we can actually give away any Ws to different users to observe the application; user A may be seeing the application from W3, and user B may be seeing it from W2 all see what they want to see. Now, while these worlds are held by them, somebody decides to start the flatten operation, and coalesces unneeded worlds into its children. Yes, now W1 is not needed anymore (as nobody is using it) and its changes can be pushed down to W2 and W2 may be re-linked under TopW. As long as the user B and user A are holding on to W2 and W3, they won't notice this has happened. When user B decides to release W2, it then can be coalesceed into W3 and still fine. But, it turned out this complicates the implementation so much, a disturbing sense that the tree structure may change under the hood, and notably, and often the parent pushed down too much information down to its children. With single-linked tree of worlds like this: TopW - W1 - W2 - W3 each world holds a nice invariant of I hold everything happens after I was created. Giving away the middle of chain to a user may be a bit confusing as his view suddenly changes when somebody initiate the flatten operation, however. (Well, this gets longer than I wanted. The bottom line is that yes, in some cases being able commit from root to leaves may be useful, but there is trade offs.) -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Alternative Web programming models?
At Mon, 13 Jun 2011 21:55:54 +0200, karl ramberg wrote: I got wondering about commit failure and cases where you needed certain objects in the world child anyway. Or two different worlds merging. Will that be possible ? Yes. You catch an exception to keep the computation going: a := WPoint2 new x: 1; y: 0. w := WWorld2 thisWorld sprout. w eval: [a y: a y + 1]. a y: 666. [w commit] on: Error do: [:ex | ]. then you can say: b := WPoint2 new. b x: (w eval: [a x]). b y: (w eval: [a y]). to salvage the values of a in w into b in the top level world. There should be more first class operations allowed, and perhaps the serializability checks and commit logic should be customizable... -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Benchmark of sqvm
Are there any plans to build such a Squeak VM? I think, better to ask, is there plains to build VM using jolt compiler, because idst having limits, because it's still backed by GCC. A plan is to unify Jolt, IdSt (and Coke) into one real thing (remember, Jolt means not quite the real thing). Making a Squeak VM on that would be a fun exercise, but I don't envision to provide a production level quality VM wouldn't be in the scope of the NSF project. At the same time, if we have a bit modular VM (whatever it means), experimenting different memory management scheme, etc. easily would have some value. -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Avoiding math precedence ambiguities
Waldemar, This makes me wonder: Who is the official voice in this project? Ian? Alan? You all together (after you've agreed on something)? What is the official voice? The precedence rule in the newer (but not so new) Etoys for OLPC follows the one you seem to like. (* / // \\ are stronger than + and -, and min: and max: are weaker than + and -.) I think this is a good idea for that audience. Great. I guess this means that your Etoys variant will have similar rules? :) You probably have figured out by now that you are not going to get any simple answers from some people... On the other hand, CASIO and SHARP (and name any manifacturers except HP) calculators are used by billions of people, and they don't follow the math precedence rules. It means that the right precedence in a language also depends on the way you input an expression, for example. You could imagine a system in which you first enter an example expression with concrete number in the calculator manner and then substitute the numbers with variables. In such a language, you would use left-to-right precedences. -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Avoiding math precedence ambiguities
On Dec 12, 2007 8:00 AM, Yoshiki Ohshima [EMAIL PROTECTED] wrote: It is good to know there are a handful! If we move even higher description, such places should be rarer, I think. Could you and Ian please clarify the official position on this topic (you two had contradicting opinions in your emails)? In a post while ago, I wrote: --- My opinion doesn't necessary reflect my employer's and colleagues, BTW. -- Etoys already has very strange precedence rules (right-to-left). Do you plan for the Etoys-like system to have math precedence? The precedence rule in the newer (but not so new) Etoys for OLPC follows the one you seem to like. (* / // \\ are stronger than + and -, and min: and max: are weaker than + and -.) I think this is a good idea for that audience. As I wrote, I'd anticipate there aren't too many of expressions with conflicts. I think this means that we don't really have to make everything right from the beginning. -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Avoiding math precedence ambiguities
There were a handful of .st files that relied on the st80-style non-precedence, which I added explicit parentheses to. It is good to know there are a handful! If we move even higher description, such places should be rarer, I think. -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goals
Hello, As far as I understand the goals for the language are: I believe that there may not be the language but the system and languages. * increased productivity (20K lines of code) Increased productivity, I think, is not a real goal. Mathematical expressions for describing physics concepts are not there primarily to increase productivity of scientists, but give concise descriptions of what is going on in the world and trys to see how simple it can be. (the productivity will probably increase, but it is not a direct goal.) * more correct code (?by using better concepts and automatic * checking?) Some correctness has to be ultimately judged by human and it would be benefited from shorter and clear descriptions. * ?better performance than Smalltalk? Good performance, yes, but not sure better than Smalltalk. I sure hope that better than existing Smalltalk implementations in practical sense. What about goals that give this language an identity: ? easy to learn ? minimalistic syntax ? very readable code ? free of unnecessary complexity ? easy and natural to think in ? attract many mainstream programmers If you say yes to most of them could you (and the other VPRI members) please order them by priority? This list is clearly yours so prioritizing it may not make sense^^; I'd say that the last one is not a *goal* (while dissemination is mentioned, it is not something a research project pursues in general). Minimalistic syntax has many definition so it is hard to agree on. And, other items sound like paraphrases of the same thing. My opinion doesn't necessary reflect my employer's and colleagues, BTW. -- Yoshiki ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] goal clarifications (was: goals)
What will the system be? Just a language generator? The system I have in my mind is basically what is described in: http://www.vpri.org/pdf/NSF_prop_RN-2006-002.pdf -- ... a practical working system that is also its own model; a whole system from the end-users to the metal that could be extremely compact (we think under 20,000 lines of code) yet practical enough to serve both as a highly useful end-user system and a system to learn about systems. I.e. the system could be compact, comprehensive, clear, high-level, and understandable enough to be an Exploratorium of itself. -- It is a working model of a personal computer which is self-supporting, and something that the user can do stuff/interact with. So, you want to have a more concise and easier to understand description of an application? Ideally, a description of *all*, or enough to describe the software (and hardware?) of computer. -- Yoshiki To think about the extent of description, physics laws for the entire universe probably doesn't require 20k lines of equations (well, I don't know for sure), and a biological system (a living body) probably requires way more than 20k to describe what is going in it (well, I don't know it for sure either). So, one could have an interesting sense of the complexity of a personal computer. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
