Re: [fonc] OT? Polish syntax
On 3/18/2012 6:54 PM, Martin Baldan wrote: BGB, please see my answer to shaun. In short: _ I'm not looking for stack-based languages. I want a Lisp which got rid of (most of the) the parens by using fixed arity and types, without any loss of genericity, homoiconicity or other desirable features. REBOL does just that, but it's not so good regarding performance, the type system, etc. fair enough... but, hmm... one could always have 2 stacks: create a stack over the stack, in turn reversing the RPN into PN, and also gets some meta going on... + 2 * 3 4 = 24 commands are pushed left to right, execution then consists of popping of and executing said commands (the pop/execute loop continues until the stack is empty). execution then proceeds left-to-right. ironically, I have a few specialized interpreters that actually sort of work this way: one such interpreter uses a similar technique to implement a naive batch-style command language. similar was also before used in a text-to-speech engine of mine. nifty features: no need to buffer intermediate expressions during execution (no ASTs or bytecode); no need for an explicit procedure call/return mechanism (the process is largely implicit, however one does need a mechanism to push the contents of a procedure, although re-parsing works fairly well); easily handles recursion; it also implicitly performs tail-call optimization; fairly quick/easy to implement; handles pause/resume easily (since the interpreter is non-recursive). possible downsides: not particularly likely to be high-performance (although an implementation using objects or threaded code seems possible); behavior can be potentially reasonably counter-intuitive; ... _ I *hate* infix notation. It can only make sense where everything has arity 3, like in RDF. many people would probably disagree. whether culture or innate, infix notations seem to be fairly popular. actually, it can be noted that the many of the world languages are SVO (and many others are SOV), so there could be a pattern here. a reasonable tradeoff IMO is using prefix notation for commands and infix notation for arithmetic. _ Matching parens is a non-issue. Just use Paredit or similar ;) I am currently mostly using Notepad2, which does have parenthesis matching via highlighting. however, the issue isn't as much with just using an editor with parenthesis matching, but more an issue when quickly typing something interactively. one may have to make extra mental effort to get the counts of opening and closing parenthesis right, potentially distracting from the task at hand (typing in a command or math expression or similar). it also doesn't help matters that the parenthesis are IMO more effort to type than some other keys. granted, C style syntax isn't perfect for interactive use either. IMO, probably the more notable issue in this case is having to type commas. one can fudge it though (say, by making commas and semicolons generally optional). one of the better syntax designs for interactive use seems to be the traditional shell-command syntax. behind this is probably C-like syntax, followed by RPN, followed by S-Expressions. although physically RPN is probably a little easier to type than C style syntax, a downside is that one may have to mentally rework the expressions prior to typing them. another downside is that of being difficult to read or decipher later. something like REBOL could possibly work fairly well here, given it has some structural similarity to shell-command syntax. _ Umm, whitespace sensitive sounds a bit dangerous. I have enough with Python :p small-scale whitespace sensitivity actually seems to work out a bit nicer than larger scale whitespace sensitivity IMO. large-scale constrains the overall formatting and may end up needing to be worked around. small-scale generally has a much smaller impact, and need not influence overall code formatting. the main merit it has is that it can reduce the need for commas (and/or semicolons), since the parser can use whitespace as a separator (and space is an easier key to hit). however, many people like to use whitespace in weird places in code, which would carry the drawback that with such a parser, such tendencies would lead to incorrect code parsing. example: foo (x) x = 3 +4 ... could likely lead to the code being parsed incorrectly in several places. otherwise, one has to write instead: foo(x) x=3+4 or possibly also allowed: foo( x) x=3+ 4 which would be more obvious to the parser. or, alternatively, whitespace sensitivity can allow things like: dosomething 2 -3 4*9-2 to be parsed without being ambiguous (except maybe to human readers due to variable-width font evilness, where font designers seem to like to often hide the spaces, but one can assume that most real programmers, if given the choice, will read code with a fixed-width font...). otherwise, I have had generally good luck
Re: [fonc] OT? Polish syntax
On 3/19/2012 5:24 AM, Martin Baldan wrote: but, hmm... one could always have 2 stacks: create a stack over the stack, in turn reversing the RPN into PN, and also gets some meta going on... Uh, I'm afraid one stack is one too many for me. But then again, I'm not sure I get what you mean. in traditional RPN (PostScript, Forth, ...). one directly executes commands from left-to-right. in this case, one pushes commands left to right, and then pops and executes them in a loop. so, there is a stack for values, and a stack for the future (commands awaiting execution). naturally enough, it flips the notation (since sub-expressions are executed first). + 2 * 3 4 = 24 Wouldn't that be + 2 * 3 4 = 14 in Polish notation? Typo? or mental arithmetic fail, either way... I vaguely remember writing this, and I think the mental arithmetic came out wrong. commands are pushed left to right, execution then consists of popping of and executing said commands (the pop/execute loop continues until the stack is empty). execution then proceeds left-to-right. Do you have to get busy with rot, swap, drop, over etc? That's the problem I see with stack-based languages. if things are designed well, these mostly go away. mostly it is a matter of making every operation do the right thing and expect arguments in a sensible order. a problem, for example, in the design of PostScript, is that people tried to give the operations their intuitive ordering, but this leads to both added awkwardness and additional need for explicit stack operations. say, for example, one can have a language with: /someName someValue bind or: someValue /someName bind though seemingly a trivial difference, one form is likely to need more swap/exch calls than the other. likewise: array index value setindex vs: value array index setindex ... dup is a little harder, but generally I have found that dup tended to appear in places where a higher-level / compound operation was more sensible. granted, for example, such compound operations are a large portion of my interpreter's bytecode ISA, but many help improve performance by optimizing common operations). an example, suppose one compiles for an operation like: j=i++; one could emit, say: load i; dup; push 1; binary add; store i; store j; with all of the lookups and type-checks along the way. also possible is the sequence: lpostinc_fn 1; lstore_f 2; (assume 1 and 2 are the lexical variable indices for i and j, both inferred fixnum). or: postinc_s i; store j; (collapsed operation, but not knowing/giving exact types or locations). now, what has happened?: the first 5 operations collapse into a single operation, in the former case, specialized also for a lexical variable and for fixnums (say, due to type-inference); what is left is a simple store. as-noted, most of this was due to interpreter-specific micro-optimizations, and a lot of this is ignored in the (newer/incomplete) JIT (which mostly decomposes the operations again, and uses more specialized variable allocation and type-inference logic). these sorts of optimizations are also to some extent language and use-case specific, but they do help somewhat with performance of a plain interpreter. similar could likely be applied to a stack language designed for use by humans, where lots of operations/words are dedicated to common constructions likely to be used by a user of the language. _ I *hate* infix notation. It can only make sense where everything has arity 3, like in RDF. many people would probably disagree. whether culture or innate, infix notations seem to be fairly popular. My beef with infix notation is that you get ambiguity, and then this ambiguity is usually eliminated with arbitrary policies of operator priority, and then you still have to use parens, even with fixed arity. In contrast, with pure Polish notation, once you accept fixed arity you get unambiguity for free and you get rid of parens for everything (except, maybe, explicit lists). For instance, in infix notation, when I see: 2 + 3 * 4 I have to remember that it means: 2 + (3*4) But then I need the parens when I mean: (2 + 3) * 4 In contrast, with Polish notation, the first case would be: + 2 * 3 4 And the second case would be: * 4 + 2 3 Which is clearly much more elegant. No parens, no operator priority. many people are not particularly concerned with elegance though, and tend to take it for granted what the operator precedences are and where the parens go. this goes even for the (arguably poorly organized) C precedence hierarchy: many new languages don't change it because people expect it a certain way; in my case, I don't change it mostly for sake of making at least some effort to conform with ECMA-262, which defines the hierarchy a certain way. the advantage is that, assuming the precedences are sensible, much more commonly used operations have higher precedence, and so don't need explicit
Re: [fonc] Naive question
You could try VHDL, it's particularly suited to time/event driven state changes, and you can make assertions in complementary languages if need be. Regards, Alexis On 19 March 2012 20:10, Benoît Fleury benoit.fle...@gmail.com wrote: Hi, I was wondering if there is any language out there that lets you describe the behavior of an object as a grammar. An object would receive a stream of events. The rules of the grammar describe the sequence of events the object can respond to. The semantic actions inside these rules can change the internal state of the object or emit other events. We don't want the objects to send message to each other. A bus-like structure would collect events and dispatch them to all interested objects. To avoid pushing an event to all objects, the bus would ask first to all objects what kind of event they're waiting for. These events are the possible alternatives in the object's grammar based on the current internal state of the object. It's different from object-oriented programming since objects don't talk directly to each other. A few questions the come up when thinking about this: - do we want backtracking? probably not, if the semantic actions are different, it might be awkward or impossible to undo them. If the semantic actions are the same in the grammar, we might want to do some factoring to remove repeated semantic actions. - how to represent time? Do all objects need to share the same clock? Do we have to send tick events to all objects? - should we allow the parallel execution of multiple scenarios for the same object? What does it make more complex in the design of the object's behavior? What does it make simpler? If we assume an object receive a tick event to represent time, and using a syntax similar to ometa, we could write a simplistic behavior of an ant this way: # the ant find food when there is a food event raised and the ant's position is in the area of the food # food indicates an event of type food, the question mark starts a semantic predicate findFood = food ?(this.position.inRect(food.area)) # similar rule to find the nest findNest = nest ?(this.position.inRect(nest.area)) # at every step, the ant move move = tick (= move 1 unit in current direction (or pick random direction if no direction)) # the gatherFood scenario can then be described as finding food then finding the nest gatherFood = findFood (= pick up food, change direction to nest) findNest (= drop food, change direction to food source) There is probably a lot of thing missing and not thought through. But I was just wondering if you know a language to do this kind of things? Thanks, Benoit. ___ 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] Naive question
Hi Benoit This is basically what publish and subscribe schemes are all about. Linda is a simple coordination protocol for organizing such loose couplings. There are sketches of such mechanisms in most of the STEPS reports Spreadsheets are simple versions of this The Playground language for the Vivarium project was set up like this For real scaling, one would like to move to more general semantic descriptions of what is needed and what is supplied ... Cheers, Alan From: Benoît Fleury benoit.fle...@gmail.com To: Fundamentals of New Computing fonc@vpri.org Sent: Monday, March 19, 2012 1:10 PM Subject: [fonc] Naive question Hi, I was wondering if there is any language out there that lets you describe the behavior of an object as a grammar. An object would receive a stream of events. The rules of the grammar describe the sequence of events the object can respond to. The semantic actions inside these rules can change the internal state of the object or emit other events. We don't want the objects to send message to each other. A bus-like structure would collect events and dispatch them to all interested objects. To avoid pushing an event to all objects, the bus would ask first to all objects what kind of event they're waiting for. These events are the possible alternatives in the object's grammar based on the current internal state of the object. It's different from object-oriented programming since objects don't talk directly to each other. A few questions the come up when thinking about this: - do we want backtracking? probably not, if the semantic actions are different, it might be awkward or impossible to undo them. If the semantic actions are the same in the grammar, we might want to do some factoring to remove repeated semantic actions. - how to represent time? Do all objects need to share the same clock? Do we have to send tick events to all objects? - should we allow the parallel execution of multiple scenarios for the same object? What does it make more complex in the design of the object's behavior? What does it make simpler? If we assume an object receive a tick event to represent time, and using a syntax similar to ometa, we could write a simplistic behavior of an ant this way: # the ant find food when there is a food event raised and the ant's position is in the area of the food # food indicates an event of type food, the question mark starts a semantic predicate findFood = food ?(this.position.inRect(food.area)) # similar rule to find the nest findNest = nest ?(this.position.inRect(nest.area)) # at every step, the ant move move = tick (= move 1 unit in current direction (or pick random direction if no direction)) # the gatherFood scenario can then be described as finding food then finding the nest gatherFood = findFood (= pick up food, change direction to nest) findNest (= drop food, change direction to food source) There is probably a lot of thing missing and not thought through. But I was just wondering if you know a language to do this kind of things? Thanks, Benoit. ___ 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] Naive question
Maybe not what you are looking for, but you might find http://awelon.org/ interesting. BR, John 2012/3/19 Benoît Fleury benoit.fle...@gmail.com: Hi, I was wondering if there is any language out there that lets you describe the behavior of an object as a grammar. An object would receive a stream of events. The rules of the grammar describe the sequence of events the object can respond to. The semantic actions inside these rules can change the internal state of the object or emit other events. We don't want the objects to send message to each other. A bus-like structure would collect events and dispatch them to all interested objects. To avoid pushing an event to all objects, the bus would ask first to all objects what kind of event they're waiting for. These events are the possible alternatives in the object's grammar based on the current internal state of the object. It's different from object-oriented programming since objects don't talk directly to each other. A few questions the come up when thinking about this: - do we want backtracking? probably not, if the semantic actions are different, it might be awkward or impossible to undo them. If the semantic actions are the same in the grammar, we might want to do some factoring to remove repeated semantic actions. - how to represent time? Do all objects need to share the same clock? Do we have to send tick events to all objects? - should we allow the parallel execution of multiple scenarios for the same object? What does it make more complex in the design of the object's behavior? What does it make simpler? If we assume an object receive a tick event to represent time, and using a syntax similar to ometa, we could write a simplistic behavior of an ant this way: # the ant find food when there is a food event raised and the ant's position is in the area of the food # food indicates an event of type food, the question mark starts a semantic predicate findFood = food ?(this.position.inRect(food.area)) # similar rule to find the nest findNest = nest ?(this.position.inRect(nest.area)) # at every step, the ant move move = tick (= move 1 unit in current direction (or pick random direction if no direction)) # the gatherFood scenario can then be described as finding food then finding the nest gatherFood = findFood (= pick up food, change direction to nest) findNest (= drop food, change direction to food source) There is probably a lot of thing missing and not thought through. But I was just wondering if you know a language to do this kind of things? Thanks, Benoit. ___ 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] Naive question
Hi All-- Just wanted to say that there is some cross-over here to electronic bus systems, and the related Producer-Consumer paradigm (PC). Some bus systems broadcast all messages to all connected nodes, ie they are unaddressed. In particular Bosch's CAN bus, used in cars, trucks, industry, and science, was designed this way. While each message (frame) has a header and body, and the header is used to select messages of interest, as originally designed the header did *not* contain a destination address, but rather a bit-pattern which each connected node can choose to accept. This is very flexible, and can be used in various ways. The Producer-Consumer paradigm broadcasts Events from one or more Producers to zero or more Consumers. A Producer sends an Event on on state *change*. Rather than using a bit-encoded meaning, it uses an arbitrary number (set of bits) to represent that meaning. The meaning of the message is the sum total of the originating change and the resultant actions as a response to the Event. Neither the Producers nor Consumers are aware of each others activities. We are adapting both of the above for use in model railroading. An example of an Event might be Evening is falling. The sending of such an event might be triggered by a button-press, a clock, or software (each an independent Producer). Similarly, the resultant actions might be: a change in the train schedule, house and lights coming on, changed traffic signal operation, dimming of the room lights, etc. Again, each of these are independent from each other. The similarities to publish and subscribe are striking, although there is no central control. Obviously braodacasting every message to every connected node is not scalable, so, we are also implementing an interest-based routing of messages onto only those bus-segments, which have nodes interested n a particular message, to reduce traffic. While the lower-level firmware and hardware are relatively fixed, the upper protocols and software start looking a lot like Fonc concepts. The upper layer protocols are quite independent, and they could easily be relabeled as domain-specific-languages. This just makes me think that this group is on the right track, and the software/hardware fraternities aren't that far apart. David OpenLCB.org On Mon, Mar 19, 2012 at 1:40 PM, Alan Kay alan.n...@yahoo.com wrote: Hi Benoit This is basically what publish and subscribe schemes are all about. Linda is a simple coordination protocol for organizing such loose couplings. There are sketches of such mechanisms in most of the STEPS reports Spreadsheets are simple versions of this The Playground language for the Vivarium project was set up like this For real scaling, one would like to move to more general semantic descriptions of what is needed and what is supplied ... Cheers, Alan -- *From:* Benoît Fleury benoit.fle...@gmail.com *To:* Fundamentals of New Computing fonc@vpri.org *Sent:* Monday, March 19, 2012 1:10 PM *Subject:* [fonc] Naive question Hi, I was wondering if there is any language out there that lets you describe the behavior of an object as a grammar. An object would receive a stream of events. The rules of the grammar describe the sequence of events the object can respond to. The semantic actions inside these rules can change the internal state of the object or emit other events. We don't want the objects to send message to each other. A bus-like structure would collect events and dispatch them to all interested objects. To avoid pushing an event to all objects, the bus would ask first to all objects what kind of event they're waiting for. These events are the possible alternatives in the object's grammar based on the current internal state of the object. It's different from object-oriented programming since objects don't talk directly to each other. A few questions the come up when thinking about this: - do we want backtracking? probably not, if the semantic actions are different, it might be awkward or impossible to undo them. If the semantic actions are the same in the grammar, we might want to do some factoring to remove repeated semantic actions. - how to represent time? Do all objects need to share the same clock? Do we have to send tick events to all objects? - should we allow the parallel execution of multiple scenarios for the same object? What does it make more complex in the design of the object's behavior? What does it make simpler? If we assume an object receive a tick event to represent time, and using a syntax similar to ometa, we could write a simplistic behavior of an ant this way: # the ant find food when there is a food event raised and the ant's position is in the area of the food # food indicates an event of type food, the question mark starts a semantic predicate findFood= food ?(this.position.inRect(food.area)) # similar rule to find the
Re: [fonc] Naive question
Better off looking at my blog. http://awelonblue.wordpress.com I'm still working on a concept of generative grammars for stable pseudo-state. It's described in a few of my blog articles, including the most recent ones. On Mon, Mar 19, 2012 at 2:52 PM, John Nilsson j...@milsson.nu wrote: Maybe not what you are looking for, but you might find http://awelon.org/ interesting. BR, John 2012/3/19 Benoît Fleury benoit.fle...@gmail.com: Hi, I was wondering if there is any language out there that lets you describe the behavior of an object as a grammar. An object would receive a stream of events. The rules of the grammar describe the sequence of events the object can respond to. The semantic actions inside these rules can change the internal state of the object or emit other events. We don't want the objects to send message to each other. A bus-like structure would collect events and dispatch them to all interested objects. To avoid pushing an event to all objects, the bus would ask first to all objects what kind of event they're waiting for. These events are the possible alternatives in the object's grammar based on the current internal state of the object. It's different from object-oriented programming since objects don't talk directly to each other. A few questions the come up when thinking about this: - do we want backtracking? probably not, if the semantic actions are different, it might be awkward or impossible to undo them. If the semantic actions are the same in the grammar, we might want to do some factoring to remove repeated semantic actions. - how to represent time? Do all objects need to share the same clock? Do we have to send tick events to all objects? - should we allow the parallel execution of multiple scenarios for the same object? What does it make more complex in the design of the object's behavior? What does it make simpler? If we assume an object receive a tick event to represent time, and using a syntax similar to ometa, we could write a simplistic behavior of an ant this way: # the ant find food when there is a food event raised and the ant's position is in the area of the food # food indicates an event of type food, the question mark starts a semantic predicate findFood= food ?(this.position.inRect(food.area)) # similar rule to find the nest findNest = nest ?(this.position.inRect(nest.area)) # at every step, the ant move move = tick (= move 1 unit in current direction (or pick random direction if no direction)) # the gatherFood scenario can then be described as finding food then finding the nest gatherFood = findFood (= pick up food, change direction to nest) findNest (= drop food, change direction to food source) There is probably a lot of thing missing and not thought through. But I was just wondering if you know a language to do this kind of things? Thanks, Benoit. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- bringing s-words to a pen fight ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
[fonc] Publish/subscribe vs. send
Here's the real naive question... I'm fuzzy about why objects should receive messages but not send them. I think I can see the mechanics of how it might work, I just don't grok why it's important. What motivates? Are we trying to eliminate the overhead of ST-style message passing? Is publish/subscribe easier to understand? Does it lead to simpler artifacts? Looser coupling? Does it simplify matters of concurrency? I feel like I'm still missing a pretty important concept, but I have a feeling that once I've grabbed at it, several things might suddenly fit and make sense. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Publish/subscribe vs. send
Hi Casey, the decoupling of the event emitters and receivers is what I find the most interesting in a pub/sub model. The publisher raises an event (in its semantic domain) and does not know what subscribers are going to receive it or what they're going to do with it. One of the advantage of this decoupling is that you can extend a system without modifying existing parts. Practically, I also encountered systems where a pub/sub model helped reducing the amount of code. A lot of objects needed to be aware of events happening in the system and instead of having to call all these objects every time something interesting was happening in the system, we raised an event for each one of them and had the objects subscribe to these events. The other advantage I also felt while using pub/sub model is that it helped me create better object-oriented design: - because you can't send direct messages, you don't use your objects as data structures - and consequently, all the code that changes the state of your object is located in the object which makes the system easier to understand The issue I have with the event systems I encountered so far is that you gain the decoupling but lose the expressiveness of message passing. The code in the subscribers often looks like this: cause = effect cause = effect cause = effect If you want to implement a complex behavior, you need to maintain state and that becomes quickly harder to understand. That's why I was wondering if you could interleave the causes and effects in a grammar to describe the behavior of an object in a more readable way, be able to reuse rules, having higher-order rules... Benoit On Mon, Mar 19, 2012 at 3:35 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Here's the real naive question... I'm fuzzy about why objects should receive messages but not send them. I think I can see the mechanics of how it might work, I just don't grok why it's important. What motivates? Are we trying to eliminate the overhead of ST-style message passing? Is publish/subscribe easier to understand? Does it lead to simpler artifacts? Looser coupling? Does it simplify matters of concurrency? I feel like I'm still missing a pretty important concept, but I have a feeling that once I've grabbed at it, several things might suddenly fit and make sense. ___ 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] Publish/subscribe vs. send
Various motivations include looser coupling, extensibility, resilience. Also, pub/sub allows modeling frameworks as regular objects. On Mon, Mar 19, 2012 at 3:35 PM, Casey Ransberger casey.obrie...@gmail.comwrote: Here's the real naive question... I'm fuzzy about why objects should receive messages but not send them. I think I can see the mechanics of how it might work, I just don't grok why it's important. What motivates? Are we trying to eliminate the overhead of ST-style message passing? Is publish/subscribe easier to understand? Does it lead to simpler artifacts? Looser coupling? Does it simplify matters of concurrency? I feel like I'm still missing a pretty important concept, but I have a feeling that once I've grabbed at it, several things might suddenly fit and make sense. ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc -- bringing s-words to a pen fight ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
