Smalltalk › Gnu

printNl question

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Duke Normandin

printNl question

I've decided to give gnu-smalltalk another chance to convince me. ;)

I'm using Canol Gökel's "Computer Programming using GNU Smalltalk" to teach myself the language.

My solution to the very first exercise in the book involves sending repetitive printLn messages to strings. It got the job done, but it also prints out the 'single quotes' along with the string. NOT what I was expecting.

However, when I used Transcript show:'blah';cr.
the output was correct (without the 'single quotes').

What's going on with printLn? I'm probably not seeing the obvious, so I'm glad that this mailing list exist and that there's still some gnu-smalltalk enthusiast lurking here. TIA ...

--
Duke Normandin

bill-auger

Re: printNl question

rather than casual explanations of the problem, it is usually
more helpful to show the exact commands and output - for
example, is this what you are seeing?

$ gst

st> 'hello' printNl
'hello'
'hello'

st> Transcript show: 'hello' ; cr
hello
Transcript

the first line is the side-effect of execution (displaying the
string)

the second line is the evaluation of the message chain
(the objects: 'hello' and Transcript) - think of those as the
return result of function evaluation, in other languages - in
both of those cases, the message chain evaluates to the receiver

this is a common idiom for REPLs - it is a little more evident in
ruby

$ irb

irb(main):001:0> puts 'hello'
hello
=> nil

irb(main):002:0> 'hello'
=> "hello"

`puts 'hello'` prints the string, then evaluates to nil
`'hello'` has no side-effect - it simply evaluates to itself

Duke Normandin

Re: printNl question

On Sun, 18 Apr 2021 19:04:10 -0400
bill-auger <[hidden email]> wrote:

> rather than casual explanations of the problem, it is usually
> more helpful to show the exact commands and output - for
> example, is this what you are seeing?
>
> $ gst
>
> st> 'hello' printNl
> 'hello'
> 'hello'
>
> st> Transcript show: 'hello' ; cr
> hello
> Transcript

Yes! That's the output I'm getting.

I've work quite a lot with various LISP REPLs, so I get it about the "double" output while working in the REPL.

However, I'm getting the same behaviour executing the source code file from the CLI.
--
Duke

Paolo Bonzini-2

Re: printNl question

In reply to this post by Duke Normandin

On 18/04/21 23:47, Duke Normandin wrote:
> What's going on with printLn?

printNl is a "debugging-oriented" output. displayNl will print without
the double quotes (for most objects except strings the output is the same).

Paolo

stes

Re: printNl question

In reply to this post by Duke Normandin

Not sure whether this helps but there also exists a #displayNl message.

bash-4.4$ gst
GNU Smalltalk ready

st> 'hello' printNl
'hello'
'hello'
st> 'hello' displayNl
hello
'hello'
st> Smalltalk version
'GNU Smalltalk version 3.2.91'

Note that for #printNl the output has '' quotes and for #displayNl it does not.

If you check the source code in Object.st (/usr/share/smalltalk/kernel/Object.st)

displayNl [
"Print a represention of the receiver, then put a new line on
the Transcript (stdout the GUI is not active). For most objects this
is simply its #printNl representation, but for strings and
characters, superfluous dollars or extra pair of quotes are stripped."

<category: 'printing'>
Transcript showCr: self displayString
]

so the description comment of displayNl explicitely talks about 'extra pair of quotes'.

----- Op 19 apr 2021 om 1:48 schreef Duke Normandin [hidden email]:

> On Sun, 18 Apr 2021 19:04:10 -0400
> bill-auger <[hidden email]> wrote:
>
>> rather than casual explanations of the problem, it is usually
>> more helpful to show the exact commands and output - for
>> example, is this what you are seeing?
>>
>> $ gst
>>
>> st> 'hello' printNl
>> 'hello'
>> 'hello'
>>
>> st> Transcript show: 'hello' ; cr
>> hello
>> Transcript
>
> Yes! That's the output I'm getting.
>
> I've work quite a lot with various LISP REPLs, so I get it about the "double"
> output while working in the REPL.
>
> However, I'm getting the same behaviour executing the source code file from the
> CLI.
> --
> Duke

Duke Normandin

Re: printNl question

In reply to this post by Paolo Bonzini-2

On Mon, 19 Apr 2021 09:48:17 +0200

> On 18/04/21 23:47, Duke Normandin wrote:
> > What's going on with printLn?

@Paolo
@stes

Thanks! Using ``displayNl'' emits the correct output to STDOUT.

It's sad and too bad that the only comprehensive gnu-smalltalk tutorial that I've been able to stumble on doesn't mention that screen output message. The existence of this mailing list is therefore a God-send to anyone learning/re-learning gnu-smalltalk.

Thanks again!
--
Duke

stes

Re: printNl question

----- Op 19 apr 2021 om 13:47 schreef Duke Normandin [hidden email]:

> Thanks! Using ``displayNl'' emits the correct output to STDOUT.

Also thanks for reporting the free book on GNU smalltalk, I wasn't aware of it:

http://stephane.ducasse.free.fr/FreeBooks.html

mentions this free e-book on GNU smalltalk.

Duke Normandin

Re: printNl question

On Mon, 19 Apr 2021 19:01:48 +0200 (CEST)
"[hidden email]" <[hidden email]> wrote:

>
> ----- Op 19 apr 2021 om 13:47 schreef Duke Normandin
> [hidden email]:
> > Thanks! Using ``displayNl'' emits the correct output to STDOUT.
>
> Also thanks for reporting the free book on GNU smalltalk, I wasn't
> aware of it:
>
> http://stephane.ducasse.free.fr/FreeBooks.html
>
> mentions this free e-book on GNU smalltalk.

No problem! I'm annotating the pdf to bring some items up-to-date as I work my way through the book. Good way to learn!

I just discovered 2 things:

1. always terminated a line of coding with a period/full-stop
2. never put a period/full-stop after a [ ..... ]

At least I think that is correct, because doing so fixed 2 scripts.
--
Duke

bill-auger

Re: printNl question

On Mon, 19 Apr 2021 11:22:27 -0600 Duke wrote:
> 1. always terminated a line of coding with a period/full-stop
> 2. never put a period/full-stop after a [ ..... ]

the period/full-stop is not a required terminator, as in the C
language - it is separator, between message chains - that is: it
is not required after the final LOC

a period/full-stop can follow a right-square-bracket ']' in most
syntax - all of these forms are valid syntax

st> ablock := [ 'ima block' displayNl ]
st> ablock := [ 'ima block' displayNl ] .
st> ablock := [ 'ima block' displayNl ] . ablock value
st> ablock := [ 'ima block' displayNl ] . ablock value .

i suppose that you are seeing an error with a period/full-stop
after a method definition - that syntax is something of a
special form for gnu-smalltalk - most smalltalk dialects do not
use square-brackets to enclose class and method definitions

see:
https://www.gnu.org/software/smalltalk/manual/gst.html#Syntax

Duke Normandin

Re: printNl question

On Tue, 20 Apr 2021 10:59:16 -0400
bill-auger <[hidden email]> wrote:

> the period/full-stop is not a required terminator, as in the C
> language - it is separator, between message chains - that is: it
> is not required after the final LOC

Here's the code that I'm using to start learning gnu-smalltalk:
" calculate everage value "
" language: SmallTalk "

| i term sum n |

i := 1.0 .
sum := 0.0 .
n := 0.0

' How many integers are we averaging? ' display.
n := stdin nextLine asInteger.

n timesRepeat: [
' Enter an integer (#' display.
i display.
') > ' display.

term := stdin nextLine asNumber.
i := i + 1.
sum := sum + term
]

' Average = ' display
(sum / n) displayNl

' That is all folks! ' displayNl

I now understand that the period/full-stop is a "statement separator" and NOT a "line terminator".

However, it seems that even though 2 or more statements occur on separate lines, they are treated as occurring on the same line and need a "period" between them. Is that correct? For example:

The 3 variable initialisation lines choke the interpreter unless they're separated by a "period.

Each line in the block of code needs to be separated with a "period" even though they appear on separate lines.

The 2nd-to-last and 3rd-to-last statements do not appear to need a "period" to separate them! Why is that?

--
Duke

mbratch

RE: printNl question

Unlike the REPL, when GNU Smalltalk statements are written in a file, even if statements are on separate lines you need the period. Between them.

Sent from Mail for Windows 10

From: [hidden email]
Sent: Tuesday, April 20, 2021 2:38 PM
To: [hidden email]
Subject: Re: printNl question

On Tue, 20 Apr 2021 10:59:16 -0400

bill-auger <[hidden email]> wrote:

> the period/full-stop is not a required terminator, as in the C

> language - it is separator, between message chains - that is: it

> is not required after the final LOC

Here's the code that I'm using to start learning gnu-smalltalk:

" calculate everage value "

" language: SmallTalk "

| i term sum n |

i := 1.0 .

sum := 0.0 .

n := 0.0

' How many integers are we averaging? ' display.

n := stdin nextLine asInteger.

n timesRepeat: [

' Enter an integer (#' display.

i display.

') > ' display.

term := stdin nextLine asNumber.

i := i + 1.

sum := sum + term

]

' Average = ' display

(sum / n) displayNl

' That is all folks! ' displayNl

I now understand that the period/full-stop is a "statement separator" and NOT a "line terminator".

However, it seems that even though 2 or more statements occur on separate lines, they are treated as occurring on the same line and need a "period" between them. Is that correct? For example:

The 3 variable initialisation lines choke the interpreter unless they're separated by a "period.

Each line in the block of code needs to be separated with a "period" even though they appear on separate lines.

The 2nd-to-last and 3rd-to-last statements do not appear to need a "period" to separate them! Why is that?

Duke