473,583 Members | 3,200 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Python syntax in Lisp and Scheme

I think everyone who used Python will agree that its syntax is
the best thing going for it. It is very readable and easy
for everyone to learn. But, Python does not a have very good
macro capabilities, unfortunately. I'd like to know if it may
be possible to add a powerful macro system to Python, while
keeping its amazing syntax, and if it could be possible to
add Pythonistic syntax to Lisp or Scheme, while keeping all
of the functionality and convenience. If the answer is yes,
would many Python programmers switch to Lisp or Scheme if
they were offered identation-based syntax?
Jul 18 '05
699 33653
Grzegorz Chrupa?a wrote:
As an example of how subjective this can be, most of the features you
mention as too complex for Python to support are in fact standard in Scheme
(true lexical scope, implicit return, no expression/statement distinction)
and yet Scheme is widely regarded as one of the simplest programming
languages out there, more so than Python.


Scheme, as a language, is arguably simpler than Python... it takes a few core
concepts and rigorously applies them everywhere. This makes the Scheme
language definition simpler than Python's. However, whether *programming in
Scheme* is simpler than *programming in Python* is a different issue
altogether. To do everyday things, should you really have to grok recursion,
deeply nested expressions, anonymous functions, complex list structures, or
environments? Of course, Python has all this as well (more or less), but they
usually don't show up in Python 101.

--
Hans (ha**@zephyrfal con.org)
http://zephyrfalcon.org/

Jul 18 '05 #91

"Grzegorz ChrupaÅ,a" <gr******@pithe kos.net> wrote in message
news:bl******** **@news.ya.com. ..
As an example of how subjective this can be, most of the features you mention as too complex for Python to support are in fact standard in Scheme (true lexical scope, implicit return, no expression/statement distinction)
Another problem with simplicity is that introducing it in one place may increase complexity in another place. [typos corrected]


[Python simplicity=>com plexity example (scopes) snipped]

[I am leaving the reduced newsgroup list as is. If anything I write
below about Lisp does not apply to Scheme specificly, my aplogies in
advance.]

There is a basic Lisp example that some Lispers tend to gloss over, I
think to the ultimate detriment of promoting that more people
understand and possibly use Lisp (in whatever version).

Specifically, the syntactic simplification of unifying functions and
statements as S-expressions aids, is made possible by, and comes at
the cost of semantic complexificatio n of the meaning of 'function
call' (or S-expression evaulation).

The 'standard' meaning in the languages I am previously familiar with
(and remember) is simple and uniform: evaluate the argument
expressions and somehow 'pass' the resulting values to the function to
be matched with the formal parameters. The only complication is in
the 'how' of the passing.

Lisp (and possibly other languages I am not familiar with) adds the
alternative of *not* evaluating arguments but instead passing them as
unevaluated expressions. In other words, arguments may be
*implicitly* quoted. Since, unlike as in Python, there is no
alternate syntax to flag the alternate argument protocol, one must, as
far as I know, memorize/learn the behavior for each function. The
syntactic unification masks but does not lessen the semantic
divergence. For me, it made learning Lisp (as far as I have gotten)
more complicated, not less, especially before I 'got' what going on.

In Python, one must explicitly quote syntactic function arguments
either with quote marks (for later possible eval()ing) or 'lambda :'
(for later possible calling). Inplicit quoting requires the alternate
syntax of either operator notation ('and' and 'or'-- but these are
exceptional for operators) or a statement. Most Python statements
implicitly quote at least part of the construct. (A print statement
implicitly stringifies its object values, but this too is special
handling.)

Question: Python has the simplicity of one unified assignment
statement for the binding of names, attributes, slot and slices, and
multiples thereof. Some Lisps have the complexity of different
functions for different types of targets: set, setq, putprop, etc.
What about Scheme ;-?

Terry J. Reedy
Jul 18 '05 #92
"Terry Reedy" <tj*****@udel.e du> writes:
Lisp (and possibly other languages I am not familiar with) adds the
alternative of *not* evaluating arguments but instead passing them as
unevaluated expressions. In other words, arguments may be
*implicitly* quoted. Since, unlike as in Python, there is no
alternate syntax to flag the alternate argument protocol, one must, as
far as I know, memorize/learn the behavior for each function. The
syntactic unification masks but does not lessen the semantic
divergence. For me, it made learning Lisp (as far as I have gotten)
more complicated, not less, especially before I 'got' what going on.
What you're talking about are called "special forms" and are definitely
not functions, and are used when it is semantically necessary to leave
something in an argument position unevaluated (such as in 'cond' or
'if', Lisp 'defun' or 'setq', or Scheme 'define' or 'set!').
Programmers create them using the macro facilities of Lisp or Scheme
rather than as function definitions. There are only a handful of
special forms one needs to know in routine programming, and each one has
a clear justification for being a special form rather than a function.

Lisp-family languages have traditionally held to the notion that Lisp
programs should be easily representable using the list data structure,
making it easy to manipulate programs as data. This is probably the
main reason Lisp-family languages have retrained the very simple syntax
they have, as well as why there is not different syntax for functions
and special forms.
Question: Python has the simplicity of one unified assignment
statement for the binding of names, attributes, slot and slices, and
multiples thereof. Some Lisps have the complexity of different
functions for different types of targets: set, setq, putprop, etc.
What about Scheme ;-?


Scheme has 'define', 'set!', and 'lambda' for identifier bindings (from
which 'let'/'let*'/'letrec' can be derived), and a number of mutation
operations for composite data types: 'set-car!'/'set-cdr!' for pairs,
'vector-set!' for mutating elements of vectors, 'string-set!' for
mutating strings, and probably a few others I'm forgetting.

--
Steve VanDevender "I ride the big iron" http://jcomm.uoregon.edu/~stevev
st****@hexadeci mal.uoregon.edu PGP keyprint 4AD7AF61F0B9DE8 7 522902969C0A7EE 8
Little things break, circuitry burns / Time flies while my little world turns
Every day comes, every day goes / 100 years and nobody shows -- Happy Rhodes
Jul 18 '05 #93
On Sat, 04 Oct 2003 17:02:41 GMT
Alex Martelli <al***@aleax.it > wrote:
As Paul Graham says (<URL:http://www.paulgraham. com/icad.html>):
or even

def foo(n):
lambda i: n += i
And this touches on yet another point of the Zen of Python:
explicit is better than implicit. Having a function
implicitly return the last expression it computes would
violate this point (and is in fact somewhat error-prone,
in my experience, in the several languages that adopt
this rule).
I don't mean to start a flamewar....ah, who am I kidding, of *course* I
mean to start a flamewar. :-)

I just wish the Zen of Python (try "import this" on a Python interpreter
for those who haven't read it.) would make it clearer that "Explicit is
better than implicit" really means "Explicit is better than implicit _in
some cases_"

Look here:
[x*x for x in [1,2,3]] [1, 4, 9]

Good grief! How could someone who doesn't understand list comprehensions
*ever* read and understand this? We'd better do it the explicit way:'
ary = []
for x in [1,2,3]: .... ary.append(x*x)
.... ary [1, 4, 9]


*Much* better! Now you don't have to understand list comprehensions to
read this code!

</sarcasm>

Of course, nobody is going to seriously suggest that list
comprehensions be removed from Python. (I hope). The point here is that,
for any level of abstraction, you have to understand how it works. (I
think) what the author of "The Zen of Python" (Tim Peters) means when
he says "Explicit is better than implicit" is "Don't do weird crazy
things behind the programmer's back, like automatically have varibles
initialized to different datatypes depending on how they are used, like
some programming language we could mention."

I agree with most of the rest of "The Zen of Python", except for the
"There should be one-- and preferably only one --obvious way to do it."
bit. I think it should be "There should be one, and preferably only one
, *easy* (And it should be obvious, if we can manage it) way to do it."

For instance, let us take the ternary operator. Ruby has at least two
constructs that will act like the ternary operator.

if a then b else c end

and

a ? b : c

The "if a then b else c end" bit works because of Ruby's "return value is
last expression" policy.

In a recent thread in comp.lang.ruby, you (Alex Martelli) said:

But for the life of me I just can't see why, when one has
"if a then b else c end" working perfectly as both an expression
and a control statement, one would WANT to weigh down the language
with an alternative but equivalent syntax "a?b:c".

<end quote>

The reason I would want to weigh down the language with an alternative
syntax is because sometimes a ? b : c is the *easy* way to do it.
Sometimes you don't want do say:

obj.method(arg1 , (if boolean then goober else lala end))

Sometimes you just want to be able to say:

obj.method(arg1 , arg2, boolean ? goober : lala)

But the Python folks seems to like having only one way to write
something, which I argee with, so long as we have at least one easy way
to write something.

So there is a balance to be struck here. Some people like the way Python
does things; some people do not. This is why we all hate each other. :-)

No, really, that's why we have different languages.
In Ruby, the spaces of methods and data are separate (i.e.,
most everything is "an object" -- but, differently from
Python, methods are not objects in Ruby), and I do not
think, therefore, that you can write a method that builds
and returns another method, and bind the latter to a name --
but you can return an object with a .call method, a la:

def outer(a) proc do |b| a+=b end end
I would probably define this as;

def outer(a)
proc { |b| a+=b }
end

I prefer the { } block syntax for one-line blocks like that. And I don't
like stick a whole function definition on one line like that. Makes it
harder to read, IMHO.
x = outer(23)
puts x.call(100) # emits 123
puts x.call(100) # emits 223

[i.e., I can't think of any way you could just use x(100)
at the end of such a snippet in Ruby -- perhaps somebody
more expert of Ruby than I am can confirm or correct...?]


I will go on a little ego trip here and assume I'm more of a Ruby expert
than you are. :-)

Yes, you are pretty much correct. There are some clever hacks you could
do, but for the most part, functional objects in Ruby come without
sugar.

Jason Creighton
Jul 18 '05 #94
On Fri, Oct 03, 2003 at 04:02:13AM -0700, Mark Brady wrote:
....
have been helped by python. I learned python then got interested in
it's functional side and ended up learning Scheme and Common Lisp. A
lot of new Scheme and Common Lisp developers I talk to followed the
same route. Python is a great language and I still use it for some
things.


Python is a gateway drug to much more dangerous stuff. Just say no to
functions as first-class objects. Before you know it you will be
snorting a dozen closing parentheses in a row.

Oren

Jul 18 '05 #95
On Sat, 04 Oct 2003 13:11:49 +0100, David Rush <dr***@aol.ne t> wrote:
Emacs. I've noticed over the years that people don't really get Emacs
religion until they've started hacking elisp. I know that the frustration
of having almost-but-not-quite the behavior I wanted on top of having all
that source code was a powerful incentive for me to learn Lisp. Of course
my apreciation of Emacs only increased as I went...


hm. i really like LISP, but still don't get through emacs. After i
learned a bit LISP i wanted to try it again, and again i failed ;) i
know vim from the in- and out- side and just feel completely lost in
emacs.

i also like vim with gtk2 support more. not because of menu or toolbar,
which are usually switched off in my config, but because of antialiased
letters. I just don't like coding with bleeding eyes anymore ;)

*to me* vim just looks and feels much more smooth than emacs, so i don't
think that hacking LISP influences the choice of the editor much. it of
course makes people *try* Emacs because of its LISP support.

Rene
Jul 18 '05 #96
On Sat, 04 Oct 2003 19:48:54 GMT, Alex Martelli <al***@aleax.it > wrote:
Bengt Richter wrote:
...
I like the Bunch class, but the name suggests vegetables to me ;-)


Well, I _like_ vegetables...
BTW, care to comment on a couple of close variants of Bunch with
per-object class dicts? ...

def mkNSC(**kwds): return type('NSC', (), kwds)()


Very nice (apart from the yecchy name;-).
or, stretching the one line a bit to use the instance dict, ^^^^^^^^^^^^^^^ ^^^^^^^^^

def mkNSO(**kwds): o=type('NSO', (), {})(); o.__dict__.upda te(kwds);
return o


I don't see the advantage of explicity using an empty dict and then
updating it with kwds, vs using kwds directly.

^^-- not the same dict, as you've probably thought of by now, but
glad to see I'm not the only one who misread that ;-)

I.e., as you know, the contents of the dict passed to type is used to update the fresh class dict.
It's not the same mutable dict object, (I had to check)
d={'foo':'to check id'}
o = type('Using_d', (),d)()
d['y']='a y value'
o.__class__.__d ict__.keys() ['__dict__', '__module__', 'foo', '__weakref__', '__doc__']

(If d were serving as class dict, IWT y would have shown up in the keys).

and also the instance dict is only a glimmer in the trailing ()'s eye
at the point the kwd dict is being passed to type ;-)
def mkNSC(**kwds): return type('NSC', (), kwds)() ... def mkNSO(**kwds): o=type('NSO', (), {})(); o.__dict__.upda te(kwds); return o ... class Bunch(object): ... def __init__(self, **kw): self.__dict__.u pdate(kw)
... for inst in [mk(x=mk.__name_ _+'_x_value') for mk in (mkNSC, mkNSO, Bunch)]: ... cls=inst.__clas s__; classname = cls.__name__
... inst.y = 'added %s instance attribute y'% classname
... print '%6s: instance dict: %r' %(classname, inst.__dict__)
... print '%6s class dict keys: %r' %('', cls.__dict__.ke ys())
... print '%6s instance attr x: %r' %( '', inst.x)
... print '%6s instance attr y: %r' %( '', inst.y)
... print '%6s class var x : %r' %( '', cls.__dict__.ge t('x','<x not there>'))
... print
...
NSC: instance dict: {'y': 'added NSC instance attribute y'}
class dict keys: ['__dict__', 'x', '__module__', '__weakref__', '__doc__']
instance attr x: 'mkNSC_x_value'
instance attr y: 'added NSC instance attribute y'
class var x : 'mkNSC_x_value'

NSO: instance dict: {'y': 'added NSO instance attribute y', 'x': 'mkNSO_x_value' }
class dict keys: ['__dict__', '__module__', '__weakref__', '__doc__']
instance attr x: 'mkNSO_x_value'
instance attr y: 'added NSO instance attribute y'
class var x : '<x not there>'

Bunch: instance dict: {'y': 'added Bunch instance attribute y', 'x': 'Bunch_x_value' }
class dict keys: ['__dict__', '__module__', '__weakref__', '__doc__', '__init__']
instance attr x: 'Bunch_x_value'
instance attr y: 'added Bunch instance attribute y'
class var x : '<x not there>'

Note where x and y went. So NSC is nice and compact, but subtly different. E.g.,
nsc = mkNSC(x='really class var')
nsc.x 'really class var' del nsc.x Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'NSC' object attribute 'x' is read-only

(Is that's a new message with 2.3?)
del nsc.__class__.x
nsc.x

Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'NSC' object has no attribute 'x'

NS was for Name Space, and C vs O was for Class vs obj dict initialization ;-)

Regards,
Bengt Richter
Jul 18 '05 #97


Andrew Dalke wrote:
Still have only made slight headway into learning Lisp since the
last discussion, so I've been staying out of this one. But

Kenny Tilton:
Take a look at the quadratic formula. Is that flat? Not. Of course
Python allows nested math (hey, how come!), but non-mathematical
computation s are usually trees, too.

Since the quadratic formula yields two results, ...


I started this analogy, didn't I? <g>

I expect most people write it more like

droot = sqrt(b*b-4*a*c) # square root of the discriminate
x_plus = (-b + droot) / (4*a*c)
x_minus = (-b - droot) / (4*a*c)
Not?:

(defun quadratic (a b c)
(let ((rad (sqrt (- (* b b) (* 4 a c)))))
(mapcar (lambda (plus-or-minus)
(/ (funcall plus-or-minus (- b) rad) (+ a a)))
'(+ -))))

:)

possibly using a temp variable for the 4*a*c term, for a
slight bit better performance.
Well it was a bad example because it does require two similar
calculations which can be done /faster/ by pre-computing shared
components. But then the flattening is about performance, and the
subject is whether deeply nested forms are in fact simpler than
flattened sequences where the algorithm itself would be drawn as a tree.
So the example (or those who stared at it too hard looking for
objections <g>) distracted us from that issue.
But isn't that flattening *exactly* what occurs in math. Let me pull
out my absolute favorite math textbook - Bartle's "The Elements
of Real Analysis", 2nd ed.
Oh, god. I tapped out after three semesters of calculus. I am in deep
trouble. :)

I opened to page 213, which is in the middle of the book.

29.1 Definition. If P is a partition of J, then a Riemann-Stieltjes sum
of f with respect to g and corresponding to P = (x_0, x_1, ..., x_n) is a
real
number S(P; f, g) of the form

n
S(P; f, g) = SIGMA f(eta_k){g(x_k) - g(x_{k-1})}
k = 1

Here we have selected number eta_k satisying

x_{k-1} <= eta_k <= x_k for k = 1, 2, ..., n

There's quite a bit going on here behind the scenes which are
the same flattening you talk about. For examples: the definiton
of "partition" is given elsewhere, the notations of what f and g
mean, and the nomenclature "SIGMA"
<snip another good example>
In both cases, the equations are flattened. They aren't pure trees
nor are they absolutely flat. Instead, names are used to represent
certain ideas -- that is, flatten them.
No! Those are like subroutines; they do not flatten, they create call
trees, hiding and encapsulating the details of subcomputations .

We do precisely the same in programming, which is part of why flattening
can be avoided. When any local computation gets too long, there is
probably a subroutine to be carved out, or at least I can take 10 lines
and give it a nice readable name so I can avoid confronting too much
detail at any one time. But I don't throw away the structure of the
problem to get to simplicity.
.. You judge the Zen of Python
using the Zen of Lisp.


Hmmm, Zen constrained by the details of a computing language. Some
philosophy! :) What I see in "flat is better" is the mind imposing
preferred structure on an algorithm which has its own structure
independent of any particular observer/mind.

I am getting excellent results lately by always striving to conform my
code to the structure of the problem as it exists independently of me.
How can I know the structure independently of my knowing? I cannot, but
the problem will tell me if I screw up and maybe even suggest how I went
wrong. I make my code look like my best guess at the problem, then if I
have trouble, I try a different shape. I do not add bandaids and patches
to force my first (apparently mistaken) ideas on the problem. When the
problem stops resisting me, I know I have at least approximated its
shape. Often there is a "pieces falling into place" sensation that gives
me some confidence.

Lisp has both SETF and "all forms return a value", so it does not
interfere in the process. In rare cases where the functional paradigm is
inappropriate, I can run thru a sequence of steps to achieve some end.
Lisp stays out of the way.

Python (I gather from what I read here) /deliberately/ interferes in my
attempts to conform my code to the problem at hand, because the
designers have decreed "flat is better". Python rips a tool from my
hands without asking if, in some cases (I would say most) it might be
the right tool (where an algorithm has a tree-like structure).

I do not think that heavy-handedness can be defended by saying "Oh, but
this is not Lisp." It is just plain heavy-handed.

kenny

"Be the ball."
- Caddy Shack


Jul 18 '05 #98
"Terry Reedy" <tj*****@udel.e du> writes:
Lisp (and possibly other languages I am not familiar with) adds the
alternative of *not* evaluating arguments but instead passing them as
unevaluated expressions. In other words, arguments may be
*implicitly* quoted. Since, unlike as in Python, there is no
alternate syntax to flag the alternate argument protocol, one must, as
far as I know, memorize/learn the behavior for each function. The
syntactic unification masks but does not lessen the semantic
divergence. For me, it made learning Lisp (as far as I have gotten)
more complicated, not less, especially before I 'got' what going on.
I'm sorry -- you appear to be hopelessly confused on this point. I
can't comment on the dark corners of Common Lisp, but I do know all of
those corners of Scheme. Scheme is a true call-by-value language.
There are no functions in Scheme whose arguments are not evaluated.
Indeed, neithen a function definition, nor an argument location, has
the freedom to "not evaluate" an argument. We can reason about this
quite easily: the language provides no such syntactic annotation, and
the evaluator (as you might imagine) does not randomly make such a
choice. Therefore, it can't happen.

It is possible that you had a horribly confused, and therefore
confusing, Scheme instructor or text.
Question: Python has the simplicity of one unified assignment
statement for the binding of names, attributes, slot and slices, and
multiples thereof. Some Lisps have the complexity of different
functions for different types of targets: set, setq, putprop, etc.


Again, you're confused. SET, SETQ, etc are not primarily binding
operators but rather mutation operators. The mutation of identifiers
and the mutation of values are fundamentally different concepts.

Shriram
Jul 18 '05 #99
On Sun, 05 Oct 2003 12:27:47 GMT,
Kenny Tilton <kt*****@nyc.rr .com> wrote:
Python (I gather from what I read here) /deliberately/ interferes in my
attempts to conform my code to the problem at hand, because the
designers have decreed "flat is better". Python rips a tool from my
hands without asking if, in some cases (I would say most) it might be
the right tool (where an algorithm has a tree-like structure).


Oh, for Pete's sake... Python is perfectly capable of manipulating tree
structures, and claiming it "rips a tool from my hand" is simply silly.

The 19 rules are general principles that encapsulate various principles of
Python's design, but they're not hard-and-fast rules to be obeyed like a
legal code, and their meanings are unspecified. I have seen the "flat is
better than nested" rule cited against creating too many submodules in a
package, against nesting loops too deeply, against making code too dense.
You can project any meaning onto them you wish, much like Perlis's epigrams
or Zen koans.

--amk
Jul 18 '05 #100

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

220
18931
by: Brandon J. Van Every | last post by:
What's better about Ruby than Python? I'm sure there's something. What is it? This is not a troll. I'm language shopping and I want people's answers. I don't know beans about Ruby or have any preconceived ideas about it. I have noticed, however, that every programmer I talk to who's aware of Python is also talking about Ruby. So it...
37
2782
by: michele.simionato | last post by:
Paul Rubin wrote: > How about macros? Some pretty horrible things have been done in C > programs with the C preprocessor. But there's a movememnt afloat to > add hygienic macros to Python. Got any thoughts about that? "Movement" seems quite an exaggeration. Maybe 2-3 people made some experiments, but nobody within the core Python developers...
267
10613
by: Xah Lee | last post by:
Python, Lambda, and Guido van Rossum Xah Lee, 2006-05-05 In this post, i'd like to deconstruct one of Guido's recent blog about lambda in Python. In Guido's blog written in 2006-02-10 at http://www.artima.com/weblogs/viewpost.jsp?thread=147358
14
2162
by: Paddy3118 | last post by:
This month there was/is a 1000+ long thread called: "merits of Lisp vs Python" In comp.lang.lisp. If you followed even parts of the thread, AND previously used only one of the languages AND (and this is the crucial bit), were persuaded to have a more positive view of the other language; (deep breath, this is a long, as well as...
206
8255
by: WaterWalk | last post by:
I've just read an article "Building Robust System" by Gerald Jay Sussman. The article is here: http://swiss.csail.mit.edu/classes/symbolic/spring07/readings/robust-systems.pdf In it there is a footprint which says: "Indeed, one often hears arguments against building exibility into an engineered sys- tem. For example, in the philosophy of...
0
7890
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
8316
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
0
8187
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
1
5691
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5367
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3837
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2322
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
1418
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
1149
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.