inquiry to Perl monks about Perl as a first programming language

The_Kernel · 03-22-2009, 01:08 AM

Quote:

Originally Posted by Sergei Steshenko

First of all, I see an error:

Which was exactly my point. I was demonstrating that 'x' is not still defined in the second function, hence the error when running.

Quote:

Third, your "def point_1d", "def point_2d" do _not_ exist in my case, i.e. I do not have anything like this in the outer namespace, and nowhere else for that matter.

True enough. However you also previously said:

Quote:

My intent was then to provide a better approximation to OO by indeed creating constructors for 1d and 2d points, and the constructors could be called as many times as one wants. I.e. I meant to convert the example from kind of "inline object" into "create on demand object".

So it also seems like you were planning on doing something similar.

Your other issues don't seem pertinent to the issue at hand, which is variable scope.

Sergei Steshenko · 03-22-2009, 01:21 AM

Quote:

Originally Posted by The_Kernel

Which was exactly my point. I was demonstrating that 'x' is not still defined in the second function, hence the error when running.

True enough. However you also previously said:

So it also seems like you were planning on doing something similar.

Your other issues don't seem pertinent to the issue at hand, which is variable scope.

Look, I've shown a simple example, effectively having two scopes.

Even though my Pyhon knowledge is superficial, I _do_ know that functions have separate scope, i.e. essentially, there are two scopes in Python:

current module
function

.

So, I can introduce an example with more than two scopes.

Anyway, with your named scopes you yet have to show a piece of code which produces the same results as mine, i.e. code which has working setters and getters.

Another important point of mine is anonymity - my scopes are anonymous, so there's no danger of name contention.

You had to introduce scope names, the names which come after 'def' statements, so each new item added in such a manner requires remembering names of previous items. I am too lazy for this - especially, because mankind has already developed languages which allow me to be lazy.

Sergei Steshenko · 03-22-2009, 01:25 AM

Quote:

Originally Posted by ghostdog74

I like my life simple, so the way i see it, i would just use a database.

Are you telling me that I am obliged to use a database to export/import parse trees ?

If yes, what for ? I need parse trees to be represented as data structures in the language I am working in, so why would I need yet another level of complexity and bugs called database ?

The_Kernel · 03-22-2009, 01:46 AM

Quote:

Originally Posted by Sergei Steshenko

Let's slightly complicate the example:

Code:

sergei@amdam2:~/junk> cat -n hash_importer_1.pl
     1  #!/usr/bin/perl -w
     2
     3  use strict;
     4
     5  my $x = 10;
     6  my $hash_ref = require './hash_to_be_imported_1.prl';
     7
     8  warn "MAIN: \$x=$x";
     9
    10  foreach my $key(keys %{$hash_ref})
    11    {
    12    warn "key/value: $key/$hash_ref->{$key}"
    13    }
sergei@amdam2:~/junk> cat -n hash_to_be_imported_1.prl
     1  my $x = 0;
     2
     3  warn "IMPORTED FILE: \$x=$x";
     4
     5  {
     6  foo => $x++,
     7  bar => $x++
     8  }
     9
sergei@amdam2:~/junk> ./hash_importer_1.pl
IMPORTED FILE: $x=0 at ./hash_to_be_imported_1.prl line 3.
MAIN: $x=10 at ./hash_importer_1.pl line 8.
key/value: bar/1 at ./hash_importer_1.pl line 12.
key/value: foo/0 at ./hash_importer_1.pl line 12.
sergei@amdam2:~/junk>

- pay attention that there is $x variable in both main program and the imported data, and both of them are separate variables despite the same name.

Can you translate this into Python ?

Code:

$ cat example_2.py 
x = 10

import my_dict
hash_ref = my_dict.dict

print 'x =', x

for key in sorted(hash_ref):
    print key, '=', hash_ref[key]

$ cat my_dict.py
x = 0

print "inside imported file, x =", x

dict = {'foo': x, 'bar': x + 1}

$ python example_2.py 
inside imported file, x = 0
x = 10
bar = 1
foo = 0

Please don't complain about me not using 'x++'

The_Kernel · 03-22-2009, 02:00 AM

So to turn this around, please show me how this small change is possible to the code you posted earlier.

Code:

$ cat example_2.py 
x = 10

import my_dict

print 'x =', x

for dict in my_dict.dict, my_dict.dict2:
    for key in sorted(dict):
        print key, '=', dict[key]

$ cat my_dict.py
x = 0

print "inside imported file, x =", x

dict = {'foo': x, 'bar': x + 1}
dict2 = {'baz': x + 2, 'blah': x + 3}

$ python example_2.py 
inside imported file, x = 0
x = 10
bar = 1
foo = 0
baz = 2
blah = 3

ghostdog74 · 03-22-2009, 02:31 AM

Quote:

Originally Posted by Sergei Steshenko

Are you telling me that I am obliged to use a database to export/import parse trees ?

no you are free to do what you want. The last i look at it, you did not say your use case for doing that is for parsing trees. Again, i have no experience on this subject, but there are Python modules for parsing trees...

Sergei Steshenko · 03-22-2009, 02:44 AM

Quote:

Originally Posted by The_Kernel

So to turn this around, please show me how this small change is possible to the code you posted earlier.

Code:

$ cat example_2.py 
x = 10

import my_dict

print 'x =', x

for dict in my_dict.dict, my_dict.dict2:
    for key in sorted(dict):
        print key, '=', dict[key]

$ cat my_dict.py
x = 0

print "inside imported file, x =", x

dict = {'foo': x, 'bar': x + 1}
dict2 = {'baz': x + 2, 'blah': x + 3}

$ python example_2.py 
inside imported file, x = 0
x = 10
bar = 1
foo = 0
baz = 2
blah = 3

This example proves my point: lack of anonymity.

You have your main program:

Code:

x = 10

import my_dict

print 'x =', x

for dict in my_dict.dict, my_dict.dict2:
    for key in sorted(dict):
        print key, '=', dict[key]

and you have the imported file:

Code:

x = 0

print "inside imported file, x =", x

dict = {'foo': x, 'bar': x + 1}
dict2 = {'baz': x + 2, 'blah': x + 3}

Your 'x' variables are separated by the 'dict' namespace, the latter is global.

This means that if you want to split the work between developers, you have to assign the global names - otherwise there can be two or more developers who can use the same 'dict' name.

My code has nothing global, I do not care which variable names are used by the developer who created the imported data.

Likewise, your earlier example:

Code:

$ cat example_2.py 
x = 10

import my_dict
hash_ref = my_dict.dict

print 'x =', x

for key in sorted(hash_ref):
    print key, '=', hash_ref[key]

$ cat my_dict.py
x = 0

print "inside imported file, x =", x

dict = {'foo': x, 'bar': x + 1}

$ python example_2.py 
inside imported file, x = 0
x = 10
bar = 1

has the same flaw - you are using 'my_dict' global entity - my code has no global entities.

Now, if your question

Quote:

show me how this small change is possible to the code you posted earlier

means the desire to be shown named import in Perl - no problem:

Code:

sergei@amdam2:~/junk> cat -n package_importer.pl
     1  #!/usr/bin/perl -w
     2
     3  use strict;
     4
     5  my $x = 10;
     6  require './Package.pm';
     7
     8  warn "inside MAIN: \$x=$x";
     9
    10
    11  foreach my $hash_ref(\%Package::hash1, \%Package::hash2)
    12    {
    13    warn "\$hash_ref=$hash_ref BEGIN";
    14
    15    foreach my $key(sort keys %{$hash_ref})
    16      {
    17      warn "k/v:  $key/$hash_ref->{$key}";
    18      }
    19
    20    warn "\$hash_ref=$hash_ref END";
    21    warn "\n\n";
    22    }
    23
    24
    25
sergei@amdam2:~/junk> cat -n Package.pm
     1  package Package;
     2
     3
     4  my $x = 0;
     5  our %hash1 = # 'our' mean global - opposed to 'my' - lexical
     6    (
     7    foo => $x++,
     8    bar => $x++
     9    );
    10
    11  our %hash2 =
    12    (
    13    doo => $x++,
    14    dah => $x++
    15    );
    16
    17  warn "inside Package: \$x=$x";
    18
    19  1; # this is is needed for standard Perl export/import, any TRUE (non-FALSE)
    20     # value is OK
sergei@amdam2:~/junk> ./package_importer.pl
Name "Package::hash2" used only once: possible typo at ./package_importer.pl line 11.
Name "Package::hash1" used only once: possible typo at ./package_importer.pl line 11.
inside Package: $x=4 at ./Package.pm line 17.
inside MAIN: $x=10 at ./package_importer.pl line 8.
$hash_ref=HASH(0x8194dcc) BEGIN at ./package_importer.pl line 13.
k/v:  bar/1 at ./package_importer.pl line 17.
k/v:  foo/0 at ./package_importer.pl line 17.
$hash_ref=HASH(0x8194dcc) END at ./package_importer.pl line 20.


$hash_ref=HASH(0x816e9c0) BEGIN at ./package_importer.pl line 13.
k/v:  dah/3 at ./package_importer.pl line 17.
k/v:  doo/2 at ./package_importer.pl line 17.
$hash_ref=HASH(0x816e9c0) END at ./package_importer.pl line 20.


sergei@amdam2:~/junk>

Now look at this:

Code:

sergei@amdam2:~/junk> cat -n example_2.py
     1  x = 10
     2
     3  import my_dict
     4
     5  print 'x =', x
     6
     7  for dict in my_dict.dict, my_dict.dict2:
     8      for key in sorted(dict):
     9          print key, '=', dict[key]
    10
    11  print "added by Sergei: inside dict x=", my_dict.x
sergei@amdam2:~/junk> cat -n my_dict.py
     1  x = 0
     2
     3  print "inside imported file, x =", x
     4
     5  dict = {'foo': x, 'bar': x + 1}
     6  dict2 = {'baz': x + 2, 'blah': x + 3}
sergei@amdam2:~/junk> python example_2.py
inside imported file, x = 0
x = 10
bar = 1
foo = 0
baz = 2
blah = 3
added by Sergei: inside dict x= 0
sergei@amdam2:~/junk>

- this your code with just one added by me line:

Code:

    11  print "added by Sergei: inside dict x=", my_dict.x

and this line shows that data inside your 'my_dict.py' is not encapsulated.

Opposed to that, if you look at my

Code:

     4  my $x = 0;

line inside 'Package.pm', you'll see that this $x is encapsulated - because it is a lexical variable, and in Perl 'use'/'require' create implicit scope, i.e. you cant access it from 'main' or another file.

So, lexical scoping is about modularity, avoiding name contention, robustness.

And, just to make it more clear, my example with 'Package' does pollute global namespace - the same way as its Python counterpart.

The_Kernel · 03-22-2009, 10:46 AM

Quote:

Originally Posted by Sergei Steshenko

This example proves my point: lack of anonymity.

I don't think I ever claimed otherwise

Quote:

Now, if your question means the desire to be shown named import in Perl - no problem:

What I was trying to point out is that the model you were using, anonymous import, didn't look able to handle the creation of more than one hash. I should also point out that if we're actually talking about data persistence Python has separate modules strictly for that purpose, which allow for the importing of multiple anonymous pieces of data.

Quote:

and this line shows that data inside your 'my_dict.py' is not encapsulated.

I never claimed it was

Sergei Steshenko · 03-22-2009, 01:35 PM

Quote:

Originally Posted by The_Kernel

I don't think I ever claimed otherwise

What I was trying to point out is that the model you were using, anonymous import, didn't look able to handle the creation of more than one hash. I should also point out that if we're actually talking about data persistence Python has separate modules strictly for that purpose, which allow for the importing of multiple anonymous pieces of data.

I never claimed it was

I can always import multiple items (hash1 ... hashN) this way

Code:

{
hash1 =>
  {
  ...
  },

hash2 =>
  {
  ...
  },
...
hashN =>
  {
  ...
  }
}

.

And when I asked to translate something into Perl, I meant without the side effect of polluting global namespace.

So, in most of the cases so far according to your code there is no appropriate translation.