Question about OperatorTable and difference between Interpreter/Scripts

View: New views
9 Messages — Rating Filter:   Alert me  

Question about OperatorTable and difference between Interpreter/Scripts

by David Nolen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hullo,

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/Scripts

by Steve Dekorte :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 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/Scripts

by David Nolen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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/Scripts

by Jeremy Tregunna :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

No. 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/Scripts

by David Nolen :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Re: Question about OperatorTable and difference between Interpreter/Scripts

by Jeremy Tregunna :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jonathan 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/Scripts

by Danya Alexeyevsky :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'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/Scripts

by Steve Dekorte :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 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/Scripts

by Steve Dekorte :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 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.
LightInTheBox - Buy quality products at wholesale price