unicon-group — Unicon Discussion

Re: [Unicon-group] lamba emulation with coroutines?

[Andrew C. <ac...@ci...>]

> Also, note that Unicon already supports CE(a,b,c) style activation (as
> the example program I gave shows), which is equivalent to [a,b,c]@CE.
> Again, you have to write your co-expression knowing that it's getting
> a list of values, but that's not too hard.
>
Interesting - I'll have a play with that in the context. I'm not fussed about 
how scrappy a Lambda function would have to be, but the place where the 
anonymous code block goes - ie on the create or { } - should avoid noise just 
to get it started.

If I come up with something really sussinct I'll share. I wonder if $define 
could be exploited to hide the noise?

Re: [Unicon-group] lamba emulation with coroutines?

[Steve W. <sb...@ta...>]

Andrew Clarke wrote:
>> How about the following:
>>
>> procedure makeLamda(ce)
>>      return (@ce, ce)
>> end
>>
>> This will perform the initial activation of the coexpression and then
>> return the coexpression.  You have to write your co-expression with that
>> in mind.
>>
> Meaning it would have to lead with a suspend?

Sorta, kinda.  Not really a suspend, but the code needs to understand
that it will be activated once as an 'initialization phase' with
no values passed in and then run until it reaches a point where it is
prepared to receive values.  The lambda() procedure:

     procedure lambda(A)
        return (@A[1], A[1])
     end

simply 'initializes' the co-expression when it is created, so the first
activation the *user sees* can take values.   So, as long as you take
this initialization phase into account you get the same behavior as
if the CE took parameters right at the start.  This initialization phase
can be looked on a bonus - you get to set things up before receiving
parameters.  If you don't have anything to set up, then starting your
co-expression with (say):

     X := @&source

will assign the 'first call' (as seen outside the lambda procedure
itself) parameters to X just as other languages can assign values to
parameters as part of a call.

Also, note that Unicon already supports CE(a,b,c) style activation (as
the example program I gave shows), which is equivalent to [a,b,c]@CE.
Again, you have to write your co-expression knowing that it's getting
a list of values, but that's not too hard.

For example, the Perl example you gave is nearly the same as:

    worker(10, 20,
           lambda { X := @&source; |(X := (X[1]*X[1]) @ &source) }
          )

{Spread out to avoid line wrap on my mailer.}

So, if worker is:

    procedure worker(a,b,ce)
        every i := a to b do
           write(i,"*",i," = ",ce(i,i))
    end

you get what you'd expect.

Not that I've tried this, mind you!

-- 
Steve Wampler     {sb...@ta...}
The gods that smiled upon your birth are laughing now. -- fortune cookie

Re: [Unicon-group] lamba emulation with coroutines?

[Andrew C. <ac...@ci...>]

> How about the following:
>
> procedure makeLamda(ce)
>      return (@ce, ce)
> end
>
> This will perform the initial activation of the coexpression and then
> return the coexpression.  You have to write your co-expression with that
> in mind.
>
Meaning it would have to lead with a suspend?


Ultimately I'm just interested in passing anonymous code blocks; it's becoming 
quite common out there

- Perl with inline subs:
         worker(10, 20, sub { my $x = shift; $x * $x })

- C# with it's
    listOfFoo.Where(x => x.Size > 10);

For instance, the code I was working on yesterday said:

    l_tmp := list()
    if not ident_sequence(l_tmp) then    # much-used procedure
        tab(0)
    else
        every buf := ! l_tmp do
            if member(qstates, buf) then
                error(buf, " already mentioned.")
            else
                insert(qstates, buf, "required")

However the error( ) method is no longer pointing to the relevant &pos because  
the entire sequence of ident is collected before the error checking loop.

A desire arose where I wanted to write (to coin a syntax)

    l_tmp := list()
    if not ident_sequence(lamba buf => if member(buf...) then error(...)) then
        tab(0)
    else
        every insert(qstates, ! l_tmp, "required")

So the error pointer shown to the user can be correct.

I can pass a little procedure to do the test and insert, but I would have to 
add more parameters on ident_sequence just to pass in the target of the test 
and insert. In general the parameter count wouldn't necessarily be fixed so 
it's all a bit loose and noisy.

I came up with:

global LHA

procedure LambdaCall(cr, args)
    local stacked
    # gut feeling - LHA needs to be reverted before the suspend happens
    suspend 3(stacked <- LHA, LHA <- args, @cr, LHA <- stacked)
end

procedure worker(n, cr)
    if LambdaCall(cr, n) then
        write("it's a member")
    else
        write("it's not a member")
end

procedure main()
    local hash

    hash := table()
    worker(10, create member(hash, LHA))
    hash[10] := 1
    worker(10, create member(hash, LHA))
end

Using LHA as a generic stack to stuff parameters but it means the code is 
still clumsy.

Overall I'm coming to the conclusion that coroutines could benefit from some 
sort of ability to receive parameters on the first activation. It has always 
seemed a bit unfortunate that the first @ discards any transmitted value.

Something like

    worker1(x, y, create :a b: codeUsing(a, b))

or

    worker{:a b c: codeUsing(a,b,c), :a b: codeUsing(a, b)}

seems to be unambiguous syntactically. I'll reserve judgment on 
attractiveness!

However a question arises in

    procedure worker(X, Y, C)
        x1 @ C

how would x1 be constructed and doled out to a and b? Perhaps the initial 
activation could be performed with

    C(X, Y)

Once again, a hypothetical discussion of an improvement that brings up several 
questions!

It's interesting to note that C# has added a YIELD operator (claiming it to be 
"like Python's" the ignorant fools)

// Method that takes an iterable input (possibly an array)
// and returns all even numbers.
public static IEnumerable<int> GetEven(IEnumerable<int> numbers) {
    foreach (int i in numbers)
        if (i % 2 == 0) 
            yield return i;
}

I believe it gets crunched into an anonymous iterator class, capturing the 
stack and other context which gets restored when the instance of the iterator 
has it's next() method called. I guess that's similar to what Icon does at 
heart, but whereas Icon uses bytecodes to perform the work, C# seems to spit 
out opcodes to emulate it every single time yield is used. Both Python and C# 
seem to be completely free of goal-directed evaluation too.

Re: [Unicon-group] lamba emulation with coroutines?

[Steve W. <swa...@no...>]

Steve Wampler wrote:
> A variant of this would be:
> 
>     procedure lamda(A)
>         return (@A[1], A[1])
>     end
> 
> which can be used as a PDCO to automatically create the coexpression, as in:
> 
>     procedure genAcc(n)
>         return lamda { while i := (n*@source)[1] do n +:= i }
>     end
> 
> a sample use is:
> 
>     procedure main()
>         a := genAcc(3)
>         b := genAcc(5)
> 
>         write("         ","a",  " ","b")
>         write("genAcc: ", a(4), " ",b(4))
>         write("genAcc: ", a(2), " ",b(3))
>     end

I should point out that this program is a Unicon solution to the
"Accumulator Generator" problem found at:

    http://www.paulgraham.com/accgen.html


-- 
Steve Wampler -- swa...@no...
The gods that smiled on your birth are now laughing out loud.

Re: [Unicon-group] lamba emulation with coroutines?

[Steve W. <swa...@no...>]

Andrew Clarke wrote:
> Hey folks,
> 
> Has anyone invented a successful way of using coroutines like lambas? I 
> want
> 
> the initial invocation of the coroutine to be able to receive 
> parameters. 

How about the following:

procedure makeLamda(ce)
     return (@ce, ce)
end

This will perform the initial activation of the coexpression and then
return the coexpression.  You have to write your co-expression with that
in mind.

A variant of this would be:

    procedure lamda(A)
        return (@A[1], A[1])
    end

which can be used as a PDCO to automatically create the coexpression, as in:

    procedure genAcc(n)
        return lamda { while i := (n*@source)[1] do n +:= i }
    end

a sample use is:

    procedure main()
        a := genAcc(3)
        b := genAcc(5)

        write("         ","a",  " ","b")
        write("genAcc: ", a(4), " ",b(4))
        write("genAcc: ", a(2), " ",b(3))
    end


-- 
Steve Wampler -- swa...@no...
The gods that smiled on your birth are now laughing out loud.

[Unicon-group] Bug Report for Unicon 11.7 Beta off website

[Bruce & B. R. <br...@dc...>]

Clinton,

The following program fails to execute on Windows XP SP2

procedure main()
	write(read())
end

using the following command to compile and link

wunicon -t test.icn

immediately generates a bug report to be sent to microsoft

See attached windows error file
-- 
regards

Bruce Rennie
(God's Own Country Downunder)
Warragul. Victoria.
Australia.

Re: [Unicon-group] Strange error when compiling the following

[Bruce & B. R. <br...@dc...>]

Clinton,

Thank you. there is supposed to be a variable name before := which I 
must have deleted accidentally. I have put this back in and it now compiles.

Thanks again - couldn't see the forest for the trees.
-- 
regards

Bruce Rennie
(God's Own Country Downunder)
Warragul. Victoria.
Australia.

[Unicon-group] lamba emulation with coroutines?

[Andrew C. <ac...@ci...>]

Hey folks,

Has anyone invented a successful way of using coroutines like lambas? I want 
the initial invocation of the coroutine to be able to receive parameters. All 
I can think of is using some cooperative globals and a layering function 
inside the function invoking the lamba-like coroutine

global A

procedure invoker(cr, args[])
    A := args
    suspend @cr
end


procedure worker(arg1, arg2, cr, curry[])
    .....
    col := "abc"
    .....
    invoker(cr, curry ||| [col])
    .....
end

procedure master()
    local hash
    hash := table()
    .....
    worker(x, y, [\hash(A[1])])
    ....
end

[assuming I've done that correctly off the top of my head]

[Unicon-group] lamba emulation with coroutines?

[Andrew C. <ac...@ci...>]

> [assuming I've done that correctly off the top of my head]

which I didn't - 

master should say:

procedure master()
    local hash
    hash := table()
    .....
    worker(x, y, create \hash[A[1]] )
    ....
end

Where did I get the idea that [ ] delineates a coroutine?

[Unicon-group] lamba emulation with coroutines?

[Andrew C. <ac...@ci...>]

Hey folks,

Has anyone invented a successful way of using coroutines like lambas? I want 
the initial invocation of the coroutine to be able to receive parameters. All 
I can think of is using some cooperative globals and a layering function 
inside the function invoking the lamba-like coroutine

global A

procedure invoker(cr, args[])
    A := args
    suspend @cr
end


procedure worker(arg1, arg2, cr, curry[])
    .....
    col := "abc"
    .....
    invoker(cr, curry ||| [col])
    .....
end

procedure master()
    local hash
    hash := table()
    .....
    worker(x, y, [\hash(A[1])])
    ....
end

[assuming I've done that correctly off the top of my head]

Re: [Unicon-group] Strange error when compiling the following

[Clinton J. <cli...@gm...>]

Bruce,

The line

       expectedtype := tab(many(' \t'), := many(&letters || &digits ||
'#_'))

has a , followed by a := that do not make sense to me and I am not sure what
you intend.
Maybe something like

       expectedtype := (tab(many(' \t')), tab(many(&letters ++ &digits ++
'#_')))

I will work on improving the completeness and correctness of our error
messages.

Regards,
Clint

Re: [Unicon-group] Strange error when compiling the following

[Bruce & B. R. <br...@dc...>]

Clinton,

The two lines are wrapped by my email client. The full file is included 
below as an attachment.

I am using the ui.exe from the latest windows beta from the Unicon website.

I have tried various changes and no difference in the message.

I am missing something but I can't see it at the moment.
-- 
regards

Bruce Rennie
(God's Own Country Downunder)
Warragul. Victoria.
Australia.

Re: [Unicon-group] Strange error when compiling the following

[Clinton J. <cli...@gm...>]

Bruce,

Do you have a newline between &digits and || ?
If so, your problem seems related to unwanted semi-colon insertion.

Clint

On Wed, Mar 17, 2010 at 3:58 AM, Bruce & Breeanna Rennie <
br...@dc...> wrote:

> Greetings to all,
>
> I am getting an error when compiling the following fragment of code
>
>  # "else": syntax error (199;270)
>
> The procedure is
>
> procedure readwriteloop()
>     local line, expectedtype, params, nextin
>     while line := read() do {
>         expectedtype := tab(many(' \t'),nextin := many(&letters ||
> &digits || '#_'))
>         if typeexists(expectedtype) then {
>             params := []
>             line[nextin:0] ? while &pos ~= pos(0) do {
>                 put(params, tab(many(', \t'),(many(&letters || &digits
> || '-.#_')) | pos(0)))}
>
>             write(makeobject ! ([expectedtype] ||| params))
>         } else {
>             write(expectedtype, " does not exist")
>         }
>     }
> end
>
> Any thoughts as to what I am missing
>
> This is a part of a system to implement the Kernel programming language
> in Unicon.
>
> --
> regards
>
> Bruce Rennie
> (God's Own Country Downunder)
> Warragul. Victoria.
> Australia.
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Unicon-group mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>

[Unicon-group] Strange error when compiling the following

[Bruce & B. R. <br...@dc...>]

Greetings to all,

I am getting an error when compiling the following fragment of code

  # "else": syntax error (199;270)

The procedure is

procedure readwriteloop()
     local line, expectedtype, params, nextin
     while line := read() do {
         expectedtype := tab(many(' \t'),nextin := many(&letters || 
&digits || '#_'))
         if typeexists(expectedtype) then {
             params := []
             line[nextin:0] ? while &pos ~= pos(0) do {
                 put(params, tab(many(', \t'),(many(&letters || &digits 
|| '-.#_')) | pos(0)))}

             write(makeobject ! ([expectedtype] ||| params))
         } else {
             write(expectedtype, " does not exist")
         }
     }
end

Any thoughts as to what I am missing

This is a part of a system to implement the Kernel programming language 
in Unicon.

-- 
regards

Bruce Rennie
(God's Own Country Downunder)
Warragul. Victoria.
Australia.

[Unicon-group] Happy Valentine's Thoughts for Windows Unicon Users

[Clinton J. <je...@cs...>]

Dear Unicon Group,

I am not sure what percentage of us are Windows users, but if any of you
were aggressively following our beloved Source Forge bug tracker this week,
you would have seen a report from a user that his Windows Unicon binaries
had triggered a Virus warning. This is very exciting. The message indicated
that the warning might be a "false positive", but I thought I should tell
everyone what I know after a bit of checking.

* The virus reported was Virus.Win32.Vampiro.7018.  According to
viruslist.com it is a "harmless" non-memory resident virus that attaches
itself to the ends of .exe files in its current directory but does nothing
else.
* The latest binaries were built in 11/2009 on a university laboratory
machine and the virus was apparently present on that machine.
* The virus was not detected by a copy of Norton Antivirus that I was using,
so we may end up switching vendors. Kaspersky and derivatives such as
F-Secure report this virus and are known to occasionally show false
positives.
* The similarity between the virus and Unicon's method of attaching our VM
bytecodes onto the ends of .exe files is interesting but the virus is
reported in
.exe files where this operation would not occur, and goes away in a clean
rebuild, so I believe it is real.
* We are building new Windows Unicon binaries presently, which we needed to
do anyway. We apologize for this inconvenience and will take greater
precautions in future.

Regards,
Clint

[Unicon-group] Linkedin Group for Unicon/Icon

[David G. <dav...@ro...>]

Folks,

I created a group on Linkedin for those that are on that system.

David

[Unicon-group] Linkedin and Unicon

[David G. <dav...@ro...>]

Hi Folks,

I've been looking at Linkedin and what happens when you connect with people outside of your specific field.  Nothing definite to report.

At any rate I started looking for unicon/icon folks on linkedin.  If you're there please send look me up.

David

[Unicon-group] Compling Unicon on 64-bit Ubuntu and Snow Leopard

[Clinton J. <cli...@gm...>]

Hi,

I have installed a 64-bit Ubuntu (along with a Mac Snow Leopard, woo hoo) in
order to address build issues reported by users on those platforms.  CVS
commits have been made that resolve many of the warning messages; I am a bit
surprised that earlier 64-bit ports had not shaken all of those out. These
fixes will percolate to uni.zip next time it gets built, they are not in
there yet.

The current status on Ubuntu is: with -O2 in Makedefs, icont does indeed
generate a buffer overflow in code that has run elsewhere for decades. When
I changed -O2 to -g in order to debug it, the buffer overflow disappeared.
>From an earlier valgrind session my hypothesis is that this is an issue with
the classic AT&T yacc parser skeleton, and that the long-term solution will
require changing over icont's parser to bison or berkeley yacc or iyacc.
This is a big enough job that it is easy to put off, but a small enough job
that a student or volunteer might manage it with some coaching on my part.
In the short term, though, the answer is to turn off -O2 and maybe turn on
-g on platforms that have this issue.

The current status on Snow Leopard is: a new configuration directory named
config/unix/amd64_macos contains the snow leopard configuration. icont,
iconx, and unicon build, but a memory violation in the gdbm library code
prevents the Unicon class libraries (and ivib, and ui, and so on) from
building. In addition to debugging this, we need a 64-bit co-expression
switch for Snow Leopard, perhaps adapted from the amd64_intel rswitch, which
has a different assembler syntax. I am aware that Snow Leopard machines are
intel 64-bit machines, the configuration name amd64_macos is for consistency
with amd64_linux, which also runs on intel processors. The name reflects the
fact that amd64 is the author of the instruction set, which intel licensed
and gives another name.

Cheers,
Clint

On Thu, Jul 9, 2009 at 3:41 PM, Wade Bowmer <st...@yc...> wrote:

> Hmm. Short answer: doesn't work.
>
> Long answer: 1. Lots and lots of warnings, mostly int/word stuff. 2. Some
> step in the make tries to delete a whole lot of .u* files that aren't
> there. 3. icont generates a buffer overflow and crashes during the build.
>

Re: [Unicon-group] Icon programming for humanists

[Barry S. <che...@ch...>]

Alan B Saichek <ab...@ea...> skribis:
> The recent discussion of un-initialized list element referencing 
> reminded me of a typo in the draft of the 2nd edition of Alan Corre's 
> "Icon Programming for Humanists".
> 
> On page 43, in example code of procedure printout()
> 
>     # Arrange info in columns and figure letter total
>       write(right(n,2),right(1[n],12))
> 
> the example intends to reference an element of a list identified by 
> letter 'l' , as in l[n] .

That's why I don't use 'l' as a variable name and don't think others
should, either. 'O' is a bad name, too.

Re: [Unicon-group] Icon programming for humanists

[Alan B S. <ab...@ea...>]

Hi Folks,

The recent discussion of un-initialized list element referencing 
reminded me of a typo in the draft of the 2nd edition of Alan Corre's 
"Icon Programming for Humanists".

On page 43, in example code of procedure printout()

    # Arrange info in columns and figure letter total
      write(right(n,2),right(1[n],12))

the example intends to reference an element of a list identified by 
letter 'l' , as in l[n] .

But, square brackets also reference positions within strings.

The examples below of implicit type conversion may be diverting; if not, 
please forgive this enthusiastic spam for Icon, Unicon, and "Icon 
Programming for the Humanities".

    procedure main()
       # '1' below represents the digit one, not the letter 'l'.

       if 1[1] = 1 then            # numerical comparison
          write("1[1] = 1")

       if 1[1] == 1 then           # lexical comparison
          write("1[1] == 1")

       if 1[1] === "1" then        # value and type comparison
          write("1[1] === \"1\"")
    end

produces:

    1[1] = 1
    1[1] == 1
    1[1] === "1"

Regards, Alan B Saichek

> Dear friends,
>
> A draft of the 2nd edition of Alan Corre's Icon Programming for
> Humanists is available for public comment;
> a link is on the Jeffery Systems page, under Books at unicon.org. We
> would appreciate corrections.
>
> Alan has generously contributed to the new edition of his book, and
> even more generously agreed that it should
> be made available in free electronic form.
>
> Cheers,
> Clint

Re: [Unicon-group] An ICON question

[Jafar Al-G. <to....@gm...>]

Charles,

    w is an empty list. w[1]  fails because 1 is an out of range index.
Accessing a list with an out of range index just fails ( not a runtime error
) and so the whole expression s:= "a" || w[1] fails  ( the concat operation
|| doesn't take place and the same for the assignment) and the execution
continues. w1 on the other hand is an uninitialized variable, it has null
value. w1:=w[1] fails and leaves w1 untouched (null). "a" || w1 takes place
and so the concat || operation tries to concatenate a string and a null in
this case which causes a runtime error.

The difference in this example  is  w[1] is a fail-able expression but w1 is
not.

Insert w1:="b" right before the line w1 := w[1] and see how it goes.

Cheers,
Jafar


On Tue, Dec 1, 2009 at 7:30 AM, <Cha...@fw...> wrote:

>
> Folks:
>
> Suppose that
>
> w := []
> w1 := w[1]
>
> It turns out that
>
> s := "a" || w[1]   # fails
>
> While,
>
> s := "a" || w1  # terminates the program with a runtime error.
>
> Please help me understand why this difference occurs.
>
> Regards,
> Charles Davis
>
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> Unicon-group mailing list
> Uni...@li...
> https://lists.sourceforge.net/lists/listinfo/unicon-group
>
>


-- 
"Let there be no compulsion in religion: Truth stands out clear from error"
[The Holy Qur'an 2:256]

"Injustice anywhere is a threat to justice everywhere"    Dr. King

Re: [Unicon-group] An ICON question

[Steve W. <swa...@no...>]

Hi Charles,

Cha...@fw... wrote:
> w := []
> w1 := w[1]

This assignment fails (silently), leaving w1 assigned &null.

> It turns out that
> 
> s := "a" || w[1]   # fails

Fails in the same way that "w1 := w[1]" fails (no value for that subscript).

> While,
> 
> s := "a" || w1  # terminates the program with a runtime error.

Since wl has value &null, this is the same as:

   s := "a" || &null

and &null cannot be converted to a string for the concatenation.



-- 
Steve Wampler -- swa...@no...
The gods that smiled on your birth are now laughing out loud.

[Unicon-group] An ICON question

[<Cha...@fw...>]

Folks:

Suppose that

w := []
w1 := w[1]

It turns out that

s := "a" || w[1]   # fails

While,

s := "a" || w1  # terminates the program with a runtime error.

Please help me understand why this difference occurs.

Regards,
Charles Davis

Re: [Unicon-group] a tweak to the Unicon object representation

[Andrew C. <ac...@ci...>]

I've often thought that an extension of the function block so it can represent 
a method, and also adding a bound method block would a nice juicy low-hanging 
fruit...

[Unicon-group] a tweak to the Unicon object representation

[Clinton J. <je...@cs...>]

Hi,

There are several aspects of Unicon's representation of objects that have
always been a little bit unpolished, a side-effect of the implementation of
classes and objects as records.  Some of these things are documented, and
usually documented as subject-to-change as required by the needs of the
implementation.

One tweak we did recently that deserves mention is that object's size, and
integer subscripting were recently corrected to ignore the two fields that
are at present reserved at the front of the object instances (a so-called
"self" reference, and a so-called "methods record").  If you are using
current CVS or the current public distributions of Unicon, the size no
longer reports being two more than the user's declared number of fields, and
the integer subscripts skip over those two fields and start at 1 instead of
3 for user fields.  The two reserved fields may in fact disappear in the
future.  The names __s and __m are still reserved for those fields.  You can
thank Jafar Al Gharaibeh for the size and subscript corrections for objects;
more exciting changes are in progress.

Cheers,
Clint