Postscript
João S. O. Bueno
mas uma linguagem que eu sempre curti é - postscript -
postscript é uma linguagem usada para desenhar páginas e controlar
impressoras - no entnato é uma lignuagem de pilha completa -
e de mais baixo nível que o scheme ainda, e na minha opinião, com uma
sintaxe mais interessante (achoq ue entendi por que é mais
interessante para mim, mas vou deixar esse tópico para outra thread).
A maior diferença é que é uma linguagem pós-fixada, em contraste com o
pré fixado do scheme.
cada token encontrado pelo interpretador é colocado na pilha de dados,
ou, se for um token para execução imediata, é executado. Eu digo que é
de mais baixo nível por que o usuário tem que manipular os dados
diretamente na pilha dentro de uma procedure - não há atribuição de
parametros a variávels pelo interpretador.
Os próprios operadores para as primitivas numéricas: add,sub, mul,
div, são indistuingveis de qualquer operador defindo pelo usuário.
"qual postscript usar" - ao contrário do scheme com dezenas de
implemetnações, para uso em máquinas genéricas uma das úncias opções é
o ghostscript (que já vem instalado em Unixes e no GNU) . e
claro...sempre dá pra fazer "telnet" pra aquela sua impressora de rede
e fazer ela trabalhar um pouco! :-)
Exemplo :
<glossary>
exch: operador para trocar os dois elementos do topo da pilha
def: operador para atribuir o ultimo elemento da pilha ao "nome" que
deve ser o penultimo elemento da pilha. Nomes sao tokes prefixados com
"/" que funcionam como strings
dup: duplica o ultimo elemento da pilha
mul, add: operadores aritméticos respectivos - consomem os dois
elementos do topo da pilha e colocam o resultado na mesma
= : tira o elemento do topo da pilha e o exibe na saída padrão
</glossary>
<code>
/square {dup mul} def
/sum_of_squares {square exch square add} def
3 4 sum_of_squares =
</code>
Adriano Ogata
>
> sei que o "cool" aqui é scheme --
> mas uma linguagem que eu sempre curti é - postscript -
>
> Eu digo que é
> de mais baixo nível por que o usuário tem que manipular os dados
> diretamente na pilha dentro de uma procedure - não há atribuição de
> parametros a variávels pelo interpretador.
Err... voltar a usar Forth? xD
Pra mim scheme é legal por ampliar horizontes. Programar usando pilha,
eu já tive bastante usando minha HP48Gx. :]
Og!
Joao S. O. Bueno
não estou entendendo a coisa aqui --
pra mim as diferenças são pros-fixado e pre-fixado basicamente 9e e
forth é otura opção legal de linguagem de pilha pos-fixada).
todas sao de baixo nível, e o obenjtivo aqui é usar isso pra ampliar
os horizontes --
opr que senão eu fico no alto nível e pronto.
Agora a hor auqe voce chega e diz algo como "scheme é muito masi
avançado que postscript e vai ser melhor para esse estudo" eu não
estou entendendo o seu ponto de vista -- pode clarificar mais?
O que tem de melhor para "ampliar os horizontes" no scheme que não
possa ser feito em postscript?
js
-><-
Adriano Ogata
>
> hmm ?
(...)
> Agora a hor auqe voce chega e diz algo como "scheme é muito masi
> avançado que postscript e vai ser melhor para esse estudo"
Hm... não disse isso. Se foi o que entendeu, desculpe, até pq eu
gostava de programar na HP (e em forth, apesar de não sentir saudades
deles).
> eu não
> estou entendendo o seu ponto de vista -- pode clarificar mais?
> O que tem de melhor para "ampliar os horizontes" no scheme que não
> possa ser feito em postscript?
Lembro de ler em algum lugar que uma das idéias de scheme é você
modelar uma linguagem na qual você escreverá sua solução. Pode não ser
esse o objetivo de scheme mas foi isso o que me marcou nela.
Postscript foi feito para descrição de página. Objetivos bem
diferentes, apesar da mesma capacidade.
O ponto sobre 'ampliar os horizontes' que escrevi era sobre usar o
SICP. (Pensei sicp e escrevi scheme... colisão na hash ;P) Dá para
acompanhar esse livro usando postscript? Talvez sim mas pessoalmente
gosto de aprender idéias novas com as ferramentas mais simples e
depois ousar nos malabarismos mentais. Por isso fiz o comentário
inicial, por achar que postscript seja uma escolha bem incomum fora do
domínio para que ela foi pensada. Mas você tem todo o direito de
defender essa idéia. Desculpe se não consegui esconder meu espanto.
:-O
Og!
na...@terra.com.br
> sei que o "cool" aqui é scheme --
> mas uma linguagem que eu sempre curti é - postscript -
Na verdade, eu ia colocar um tópico a respeito: sei
que o foco é Scheme, mas seria interessante, quando
possível (isto é, se o tempo permitir, se houver dis-
posição, etc.) tentar implementar as soluções em ou-
tras linguagens.
Eu mesmo estava pensando em aproveitar o ensejo pra
estudar também Haskell e Ocaml (se possível, o tempo
permitir, etc). Pretendia fazer isso privadamente, mas
se houver interesse, eu não acharia ruim se quem esti-
ver estudando outras linguagens postasse suas soluções
aqui.
Então, por mim, se o JS quiser colocar soluções em PS,
nada contra. Mas, se o grupo inteiro preferir manter o
foco, tudo bem também.
---
José Alexandre Nalon
na...@terra.com.br
Rodrigo Bernardo Pimentel
> Então, por mim, se o JS quiser colocar soluções em PS,
> nada contra. Mas, se o grupo inteiro preferir manter o
> foco, tudo bem também.
Eu acho importante manter o foco. Note que isto não quer dizer que outras
linguagens não são bem-vindas, mas acho legal não desvirtuarmos. Minha
sugestão é, quem quiser aproveitar e fazer implementações ou discussões
em/sobre outra linguagem, beleza, mas tenha bem claro que é um desvio, e não
deve se alongar.
rbp
Luciano Ramalho
existe o Ghostscript dá até mais vontade (antes os interpretadores
Postscript eram super-proprietários e em geral só existiam embutidos
nas impressoras.
Em princípio, qualquer linguagem de programação Turing-completa serve
para seguir o SICP (na pior das hipóteses você implementa um
interpretador Scheme em Postscript, né?). Mas o livro já é
suficientemente desafiador, na minha opinião, para ser suficientemente
"interessante" mesmo que a gente use só o Scheme. (Por sinal, acho
surpreendente você dizer que Scheme é uma linguagem de baixo nível,
JS... mas essa papo fica para outra thread.)
Então eu concordo com o R que o foco principal deve ser Scheme mesmo,
mas claro que sempre será interessante quando pintarem comparações.
De qualquer modo, por mim os exercícios resolvidos em outras
linguagens são super bem vindos no repositório. Eu mesmo estou
pensando em resolver exercícios em Python de vez em quando, então
claro que Postscript, Haskell e Occam são bem vindas, assim como
Forth, Java, Cobol...
Na verdade, já existe um site com parte dos exercícios resolvidos em
várias linguagens [1] (achei o link no artigo sobre o SICP na
Wikipedia).
[1] http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages
Mas como aqui não é faculdade, não se ganha absolutamente nada
copiando soluções prontas, então vamos fazer tudo de novo, reinventar
a roda mesmo, melhor ou pior, não importa desde que cada um invente a
sua!
[ ]s
Luciano
Kao
chamada Factor[1] esses dias. Eu não conhecia o paradigma e achei
legal para "ampliar os horizontes" tb :)
O que eu mais gostei dessa linguagem aí é q ela tem um enfoque bem
prático e já vem com uma biblioteca padrão bastante completa[2]. Eu
fiquei bem interessado em aprendê-la, mas por enqto não fiz mais do q
instalar o Fuel (mode pro emacs com várias facilidades para factor) e
brincar com exemplos iniciais.
--
Kao
[1] http://factorcode.org/
[2] http://docs.factorcode.org/content/article-vocab-index.html
José Alexandre Nalon
Em Thursday 25 June 2009 18:21:24 Kao escreveu:
> Aproveitando que o JS gosta de linguagens com pilha, eu conheci uma
> chamada Factor[1] esses dias.
Valeu pelo link. Só pra colocar um pouco mais de lenha na fogueira,
muito embora sem criar polêmica: eu sempre achei que a sintaxe de
notação polonesa reversa (o site chama de "linguagem concatenativa",
eu não conhecia a denominação) _extremamente_ intuitiva, possivelmente
mais intuitiva que a notação pré-fixada do LISP -- desde que você
se acostume com ela. Eu não sei quanto aos outros participantes des-
ta lista, mas quem é engenheiro, certamente, já se acostumou. :)
O interessante é que, muito embora as implementações de notação pós-
fixada em geral sejam de linguagens de baixo nível, eu sempre pensei
que essa sintaxe pode ser facilmente adaptada para linguagens de al-
tíssimo nível. Se for pensar bem, a passagem de mensagens para obje-
tos é notação reversa -- e o Smalltalk não é muito diferente dessa
filosofia.
Assim, em linguagens de pilha, o paradigma seria, basicamente: um
objeto pilha que recebe mensagens. Se a pilha compreende a mensagem
(eg.: drop, rotate, swap), executa o comando; se a mensagem é um ob-
jeto reconhecido, a pilha o armazena no topo; caso contrário, a men-
sagem é delegada para o objeto no topo da pilha. Não dá pra ser mais
simples que isso.
Eu sempre quis montar uma linguagem de alto nível baseado em pilhas,
mas nunca tive tempo. Projetar uma linguagem não é mole, e implemen-
tar é pior ainda. :) Mas possivelmente Factor já ocupou o nicho.
--
José Alexandre Nalon
na...@terra.com.br
Carlos da Silva Santos
> Aproveitando que o JS gosta de linguagens com pilha, eu conheci uma
> chamada Factor[1] esses dias. Eu não conhecia o paradigma e achei
> legal para "ampliar os horizontes" tb :)
> O que eu mais gostei dessa linguagem aí é q ela tem um enfoque bem
> prático e já vem com uma biblioteca padrão bastante completa[2]. Eu
> fiquei bem interessado em aprendê-la, mas por enqto não fiz mais do q
> instalar o Fuel (mode pro emacs com várias facilidades para factor) e
> brincar com exemplos iniciais.
>
com os erros que hoje parecem ridiculos em outras linguagems. Por
exemplo, os strings do factor são unicode desde o começo ( lembra
quando a gente achava que os strings em java eram mesmo unicode? :-)
Outra coisa legal é que todas as operações gráficas são em 3d e a
linguagem já tem suporte a quaternions (que simplifica aplicar
rotações em objetos). Mas eu nunca me animei a tentar, o que estou
falando é de ler o blog do Slava Pestov, criador do Factor.
[]s
Carlos
guaracy
> chamada Factor[1] esses dias. Eu não conhecia o paradigma e achei
> legal para "ampliar os horizontes" tb :)
> O que eu mais gostei dessa linguagem aí é q ela tem um enfoque bem
> prático e já vem com uma biblioteca padrão bastante completa[2]. Eu
> fiquei bem interessado em aprendê-la, mas por enqto não fiz mais do q
> instalar o Fuel (mode pro emacs com várias facilidades para factor) e
> brincar com exemplos iniciais.
eu
comento, mesmo depois de tanto tempo. :-)
Conheci a linguagem no início e achei legal a intenção do Slava. No
início o ambiente era baseado na SDL e meio tosco. Ficou bem melhor de
lá para cá. Considerando que ele era o único desenvolvedor, fez
bastante coisa em pouco tempo. Ele também é autor do JEdit feito em
Java. Se alguém falar em Java para ele agoa, é pedir briga. :-)
Fiz dois tutoriais na época na época. Coloquei agora o segundo na
internet. Ficou meio lento mas é possível ter uma idéia de alguns
aspectos interessantes, como baixar o nível na própria linguagem.
http://photoshosting.com/?page=view&id=8d62b2219&name=factor2.swf&q=high&height=376&width=567
Guaracy
Ricardo Bánffy
stack-oriented. Foi também uma das primeiras vezes em que "caiu a
ficha" de que fazer algo muito diferente do resto da manada é bem
legal (a primeira foi com calculadoras HP e Casio nas provas de
cálculo numérico, mas isso é outra história). O divertido, em
comparação às outras arquiteturas que o pessoal apresentou naquele
semestre, é que enquanto todos tinham assemblers, eu tinha um
compilador FORTH.
Umas semanas atrás eu achei a pasta com os metros e metros quadrados
de papel em que ele foi entregue (infelizmente não havia nem sinal do
disquete com o arquivo OrCAD). Um dia eu ainda quero aprender alguma
HDL pra poder implementá-la em uma FPGA.
On 19 jun, 16:24, Adriano Ogata <akog...@gmail.com> wrote:
> 2009/6/19 João S. O. Bueno <gwid...@gmail.com>