|
View:
New views
9 Messages
—
Rating Filter:
Alert me
|
|
|
Question about OperatorTable and difference between Interpreter/ScriptsHullo,
First time posting to the list, and just starting to play around with Io. I'm trying to understand how to use OperatorTable based on previous examples that have been posted. First question, I've noticed a very curious discrepancy between running scripts interactively and running them via the io shell command. The following bit of code: OperatorTable addOperator("=>", 15) Object setSlot("=>", method(arg, list(self, arg))) Works fine when run interactively. However when I run it via the io shell command, it totally fails- it returns list(firstArg, nil). Also I've noticed an even stranger thing which is that if I run the following interactively: MyEnvironment := Object clone MyEnvironment OperatorTable := OperatorTable clone MyEnvironment do( OperatorTable addOperator("=>", 15) setSlot("=>", method(arg, list(self, arg))) ("David" => 5) print ) MyEnvironment OperatorTable == OperatorTable returns true While when run via the shell the two are different. Seems to me that I missing something about the way Io works. Is it possible to declare new operators without using the OperatorTable object? Many, many thanks, David |
|
|
Re: Question about OperatorTable and difference between Interpreter/ScriptsOn 2008-05-20, at 8:55 PM, david.nolen wrote: > Is it possible to declare new operators without using the > OperatorTable object? Yes, you can declare them like any other method name. For example: Number $! := method(v, self .. "!$" .. v) Io> 1 $!(2) ==> 1!$2 You only need the OperatorTable for setting precedence of operators - like if you wanted to be able to express the above without adding ()s to specify the argument. |
|
|
Re: Question about OperatorTable and difference between Interpreter/ScriptsIs it possible to add operator behavior so that it's not global? In
the same way that modifying the behavior of squareBrackets and curlyBrackets can be localized to a scope? I have a feeling it comes back to this issue: Array := List clone Array == List >>> true Hash := Map clone Hash == Map >>> false Is this an optimization thing? For example I came up with the following: MyEnvironment := Object clone MyEnvironment do( # clone the map object Hash := Map clone # Sequence := Sequence clone // doesn't work, darn # define a new operator on Sequences Sequence >> := method(arg, return list(self, arg)) # override curlyBrackets in MyEnvironment curlyBrackets := method( h := Hash clone keys := call evalArgs map(x, x at(0)) values := call evalArgs map(x, x at(1)) h addKeysAndValues(keys, values) return h ) # override square brackets in Hash Hash squareBrackets := method( return self at(call evalArgs at(0)) ); # override print Hash asString := method( temp := self map(k, v, (k .. ": " .. v)) return ("{"..(temp join(", ")).."}") ) # our hash syntax myHash := { "first" >> "John", "last" >> "Smith" } aHash := { "type" >> (Hash type), "value" >> myHash } myHash println myHash["first"] println aHash println ) # global scope affected ("test" >> 5) println The effects of squareBrackets and curlyBrackets are completely local, but changing operators is not. IO is a pretty amazing language. David |
|
|
Re: Question about OperatorTable and difference between Interpreter/ScriptsNo. The OperatorTable manipulations happen at the parsing phase.
-- Jeremy Tregunna jtregunna@... On 21-May-08, at 4:40 AM, David Nolen wrote: > Is it possible to add operator behavior so that it's not global? In > the same way that modifying the behavior of squareBrackets and > curlyBrackets can be localized to a scope? > > I have a feeling it comes back to this issue: > > Array := List clone > Array == List > >>> true > > Hash := Map clone > Hash == Map > >>> false > > Is this an optimization thing? For example I came up with the > following: > > MyEnvironment := Object clone > > MyEnvironment do( > > # clone the map object > Hash := Map clone > # Sequence := Sequence clone // doesn't work, darn > # define a new operator on Sequences > Sequence >> := method(arg, return list(self, arg)) > > # override curlyBrackets in MyEnvironment > curlyBrackets := method( > h := Hash clone > keys := call evalArgs map(x, x at(0)) > values := call evalArgs map(x, x at(1)) > h addKeysAndValues(keys, values) > return h > ) > > # override square brackets in Hash > Hash squareBrackets := method( > return self at(call evalArgs at(0)) > ); > # override print > Hash asString := method( > temp := self map(k, v, (k .. ": " .. v)) > return ("{"..(temp join(", ")).."}") > ) > > # our hash syntax > myHash := { "first" >> "John", "last" >> "Smith" } > aHash := { "type" >> (Hash type), "value" >> myHash } > > myHash println > myHash["first"] println > aHash println > ) > # global scope affected > ("test" >> 5) println > > The effects of squareBrackets and curlyBrackets are completely > local, but changing operators is not. > > IO is a pretty amazing language. > > David > |
|
|
Re: Question about OperatorTable and difference between Interpreter/ScriptsCurious, is localizing operators to a scope a planned feature? It
seems like this would be a very powerful extension to the language, allowing for people to make all kinds of interesting DSLs that interoperable. Are there considerations that make this unrealistic? David |
|
|
Re: Question about OperatorTable and difference between Interpreter/ScriptsJonathan Wright would be a better person to ask about this, as he
wrote the support. -- Jeremy Tregunna jtregunna@... On 21-May-08, at 3:23 PM, David Nolen wrote: > Curious, is localizing operators to a scope a planned feature? It > seems like this would be a very powerful extension to the language, > allowing for people to make all kinds of interesting DSLs that > interoperable. Are there considerations that make this unrealistic? > > David > > ------------------------------------ > > Yahoo! Groups Links > > > |
|
|
Re: Question about OperatorTable and difference between Interpreter/ScriptsI've researched the matter on how to make this possible, and all I
remember is it not being difficult to do at expense of a little performance loss (to lookup OperatorTable whenever it is required instead of using cached reference; I'm not sure if it is a big performance loss, or not). But it is only easy to make Io use OperatorTable for parsing strings for doString or doFile. For now I discarded the idea, as I found it not truly useable after all (it is good if one wants to precisely mimic behavior of other languages, and it's good to make things more logically aestetic (as it is now, OperatorTable is only suitable for interactive sessions, projects, that are not going to share their code and to simplify adding new operations into core), but it is not really needed for either DSL's or really abstract really dynamic programming). I could re-research it and make a patch, though, if anyone needs it... Cheers, - Danya |
|
|
Re: Question about OperatorTable and difference between Interpreter/ScriptsOn 2008-05-21, at 1:40 AM, David Nolen wrote: > Is it possible to add operator behavior so that it's not global? In > the same way that modifying the behavior of squareBrackets and > curlyBrackets can be localized to a scope? You could swap the operator table as needed and can actually implement any syntax by swapping the implementation of Compiler messageForString() as needed. That said, I think it's worth approaching adding complexity (in this case syntactic) with caution. There is a difference between design (whose purpose is to serve carefully considered functional goal) and decoration (whose purpose is to impress others with conspicuous complexity) and it's easy to stray from the former to the later to the other without realizing it. - Steve |
|
|
Re: Question about OperatorTable and difference between Interpreter/ScriptsOn 2008-05-21, at 2:04 PM, Steve Dekorte wrote: > from the former to the later to the other without realizing it. * from the former to the later without realizing it. |
| Free Forum Powered by Nabble | Forum Help |